------- Additional Comments From tbptbp at gmail dot com 2005-04-26 12:45
-------
Let's have some more fun.
Take the silly testcase up there, add this:
struct foo_t {
bool dummy;
__attribute__ ((always_inline)) foo_t() {}
};
change finalblow into that:
bool finalblow(const __m128 a, const __m128 b, const __m128 c, const __m128 d,
const __m128 e, const __m128 f) {
foo_t bar[4];
return bar[0].dummy &
bloatit(a,b) & bloatit(c,d) & bloatit(e,f) & bloatit(a,c) &
bloatit(b,d) & bloatit(c,e) & bloatit(d,f);
}
and with the same compiler & flags you'll get this interesting snippet, from
finalblow:
...
4005ea: data16 <-- sure that loop deserves to be aligned
4005eb: data16
4005ec: nop
4005ed: data16
4005ee: data16
4005ef: nop
4005f0: inc %eax
4005f2: cmp $0x4,%eax
4005f5: jne 4005f0 <finalblow(float __vector, float __vector, float
__vector, float __vector, float __vector, float __vector)+0x40>
...
In case you're wondering, yes that's the constructor.
Again, that testcase is a bit artificial.
But i've just spent an hour tracking what was producing such an interesting
aligned empty loop in my app: same symptoms, but triggered differently; the
constructor was empty and not always_inline, but apparently some treshold was
met (lots of inlining around) and tada... instant contribution to the global
warming for peanuts :)
I'm certainly not qualified, but i'll dare to say that something's fishy wrt
inlining.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21195
