Thread: Re: [PATCHES] equal() perf tweak

Re: [PATCHES] equal() perf tweak

From
Andrew Dunstan
Date:
Tom Lane wrote:

><snip> excellent scheme for improving List </snip>
>  
>

Just a thought - if we are messing with the List definition should we at 
the same time address the strict aliasing issues arising from Node's 
multiple personalities (I think it is the main offender).

Or is the intention never to do this, or not any time soon? (Either is 
OK, although I suspect it will have to happen sometime as more compilers 
start relying on the C99 rules more aggressively).

cheers

andrew



Re: [PATCHES] equal() perf tweak

From
Tom Lane
Date:
Andrew Dunstan <andrew@dunslane.net> writes:
> Just a thought - if we are messing with the List definition should we at 
> the same time address the strict aliasing issues arising from Node's 
> multiple personalities (I think it is the main offender).

> Or is the intention never to do this, or not any time soon?

I have no intention of messing with the Node concept; it's built into
the backend far too firmly to consider any significant change.

I don't think we understand exactly what we'd have to avoid in order to
enable strict aliasing, but if it requires getting rid of Node then it
ain't happening.  (I doubt that it does, anyway.  I think the issues are
probably quite localized.  The main problem I see is that we don't have
any trustworthy check to find out everyplace that strict aliasing could
cause problems.)
        regards, tom lane


Re: [PATCHES] equal() perf tweak

From
Andrew Dunstan
Date:
Tom Lane wrote:

>Andrew Dunstan <andrew@dunslane.net> writes:
>  
>
>>Just a thought - if we are messing with the List definition should we at 
>>the same time address the strict aliasing issues arising from Node's 
>>multiple personalities (I think it is the main offender).
>>    
>>
>
>  
>
>>Or is the intention never to do this, or not any time soon?
>>    
>>
>
>I have no intention of messing with the Node concept; it's built into
>the backend far too firmly to consider any significant change.
>
>I don't think we understand exactly what we'd have to avoid in order to
>enable strict aliasing, but if it requires getting rid of Node then it
>ain't happening.  (I doubt that it does, anyway.  I think the issues are
>probably quite localized.  The main problem I see is that we don't have
>any trustworthy check to find out everyplace that strict aliasing could
>cause problems.)
>
>  
>

*nod* (I made the last point previously :-) )

I don't claim that my understanding is anything like complete.

However, in the case of gcc it might be easier to fix than you think, 
without a lot of declaration rearranging, using gcc's new "may_alias" 
type attribute, (see 
http://gcc.gnu.org/onlinedocs/gcc-3.3.2/gcc/Type-Attributes.html ) which 
could probably be added in a very few places (e.g. Node's typedef) to 
fix things.

Of course, that doesn't help when vendor foo's compiler starts doing 
type-based alias analysis.

Still, to quote "Airplane", that's not important right now.

cheers

andrew