[Bug rtl-optimization/44288] [Extended inline asm] wrong assembly generation on IA32

[dg dot recrutement31 at gmail dot com]

------- Comment #9 from dg dot recrutement31 at gmail dot com  2010-05-27 12:21 -------
(In reply to comment #7)
> You are wrong.  It is user's responsibility to choose correct constraints for
> the inline assembly, the compiler doesn't try to understand what the inline
> assembly is doing or even check its semantics, all it does is perform
> replacements in it (replacing %0, %1, %2 in this case).
> Not every constraint is suitable for every use in the assembly obviously,
> otherwise we wouldn't need multiple constraints.
> The "g" constraint allows a register, immediate or memory, all must be valid in
> the instruction and it is up to the compiler which one it chooses.
> "g" constraint is usable say for mov eax, %2; which can work well with
> registers, immediates or memory.  But as you use [%2] instead, memory isn't
> valid, all that is valid is either a register or register + immediate or
> register + X*register2 + immediate (the usual i?86 addressing modes).

Yes, yes, but ...

I've (naively) delete [] of deferencing :

inline T operator*(void)
{
        T item;
        __asm__
        (
                "\
                .intel_syntax noprefix;     \n\
                mov gs, %1;                 \n\
                mov %0, gs:%2;              \n\
                "
                :"=q"(item)
                :"r"(this->segmentSelector), "g"(this->offset)
        );
        return item;
}

The example works because of static parameter '&main'.

But, in some others cases, it tries to generate :

mov al, gs:eax

... Argh !!

So, the inline assembly can't fully participate to optimization.

Should be nice, if it did it.

I wonder if inline RTL would be better to use (if it was supported)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44288