On 23 May 2014 04:44, Artur Skawina via Digitalmars-d <[email protected]> wrote: > On 05/22/14 17:51, Manu via Digitalmars-d wrote: >> On 22 May 2014 23:53, Artur Skawina via Digitalmars-d >> <[email protected]> wrote: >>> On 05/22/14 12:54, Manu via Digitalmars-d wrote: >>>> To address this, in GCC, you can use attributes or pragma's to specify >>>> the code-gen on a per-function basis, ie: __attribute__ ((__target__ >>>> ("sse2"))), or #pragma GCC target ("sse2") >>>> To access this with GDC, I use the code above. >>> >>> Keep in mind that GDC will not inline those functions into callers >>> marked with a different (or no) target attribute. >> >> Umm... really? Why? >> Well, that's a colossal failure. > > That is how GCC handles the attributes. Somebody more familiar with gcc > development might give a better answer, but AIUI the reason is that if > you mark a function with one "target" then the compiler shouldn't emit > code for another, possibly unsupported, target. > Yes, this does not really make sense, when /direct/ "cross-target" calls > are allowed. A sane(r) approach would be to support just /indirect/ calls, > but that's not what GCC does. > >> So... is it impossible then to force the compiler to emit specific >> opcodes in GCC? The problem is the intrinsics don't actually map to >> opcodes, they are reinterpreted however the compiler likes :/ > > /I/ would just use inline asm. The target attributes can be useful when > auto-vectorization kicks in etc, though.
Impossible to make inline asm efficient. Compiler can't pipeline, reorder, eliminate redundancies, compound mul+add sequences into madd, that sort of stuff... Intrinsics are necessary these days. It's just annoying the intrinsics don't actually mean what they say they mean.
