Re: [PATCHES] equal() perf tweak
От | Andrew Dunstan |
---|---|
Тема | Re: [PATCHES] equal() perf tweak |
Дата | |
Msg-id | 3FA7F53D.30709@dunslane.net обсуждение исходный текст |
Ответ на | Re: [PATCHES] equal() perf tweak (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: