| 1 |
On Fri, 1 Jul 2011, Frank Peters wrote: |
| 2 |
|
| 3 |
> On Fri, 1 Jul 2011 00:58:46 +0000 (UTC) |
| 4 |
> Duncan <1i5t5.duncan@×××.net> wrote: |
| 5 |
> |
| 6 |
>> |
| 7 |
>> I had wondered if this might be an "undefined behavior" optimization bug, |
| 8 |
>> |
| 9 |
> |
| 10 |
> Well, the amd64 users list may not be the appropriate place to discuss |
| 11 |
> C programming, but the problem here stems from attempting to do things |
| 12 |
> with C that are not supposed to be done with C. Such things are aptly |
| 13 |
> called "tricks" because they stray away from the convention. |
| 14 |
|
| 15 |
I don't think that is true - C has ALWAYS had rules on strict aliasing, |
| 16 |
even from the first attempts at standardization. |
| 17 |
|
| 18 |
Unfortunately it is only recently that common compilers and hardware have |
| 19 |
really taken advantage of the way the language works to give better |
| 20 |
optimizing performance by storing more variables in registers rather than |
| 21 |
reloading pointers from memory every time. Mostly this is due to the |
| 22 |
small number of registers in the x86 architecture, doesn't lend itself to |
| 23 |
these optimisations as well as other architectures. Contrast with Itanium |
| 24 |
for example with lots of registers, some of which are designed to be |
| 25 |
preserved across a function call. FORTRAN compilers have taken advantage |
| 26 |
of aliasing optimizations right from the beginning (ie, since the |
| 27 |
1960's!), and commodity C compilers are only now just catching up! So |
| 28 |
these are hardly new optimizations. |
| 29 |
|
| 30 |
> |
| 31 |
> Ideally, I suppose, for these purposes would be to use assembly language |
| 32 |
> routines mixed into the C code. But this is not as easy as with the |
| 33 |
> "tricks." |
| 34 |
|
| 35 |
Not at all, it is about producing more efficient assembly, using the |
| 36 |
language rules that have existed practically forever. If programmers have |
| 37 |
become accustomed to violating those rules, then they'll just have to get |
| 38 |
accustomed to not violating them. The rules aren't hard! And if you DO |
| 39 |
want to alias pointers of different types, then there are well-defined |
| 40 |
ways of doing that, and the resulting code tends to be much more readable |
| 41 |
too. |
| 42 |
|
| 43 |
Regards, |
| 44 |
Ian |
Archives