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