[Bug target/21195] SSE intrinsics not inlined, sometimes.

[tbptbp at gmail dot com]

------- 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