Subject: Re: com rumblings...
To: Bill Studenmund <wrstuden@netbsd.org>
From: Garrett D'Amore <garrett_damore@tadpole.com>
List: tech-kern
Date: 06/19/2006 11:25:01
Bill Studenmund wrote:
> On Thu, Jun 15, 2006 at 02:38:24PM -0700, Garrett D'Amore wrote:
>   
>> I'm not sure how good gcc's optimizer is at detecting that:
>>
>>     struct {
>>        bus_space_handle_t h;
>>        bus_space_tag_t   t;
>>     } s;
>>
>>     bus_space_write_1(s->t, s->h, OFFSET1, VAL1);
>>     /* possibly insert code that doesn't modify s */
>>     bus_space_write_1(s->t, s->h, OFFSET2, VAL2);
>>
>> both values of s->t and s->h are really the same and could be cached in
>> registers without having to dereference thru s for each
>> bus_space_write_1 call.
>>     
>
> It probably can't assume that if there's a function call in there
> somewhere. Assign them to local variables & be explicit that they can be
> cached. :-)
>
> The problem is that the compiler can't (in general) tell if they get 
> changed across a subroutine call. The call can, in principle, block and 
> then things in the structs can get changed.
>   

I suspect if there is a subroutine call, then the cost impact of the
extra memory dereference is probably dwarfed by the subroutine call.

The platforms where this really, really matters probably use macros.

    -- Garrett
> Obviously if we're using macros, there's no problem. :-)
>
> Take care,
>
> Bill
>   


-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191