"+m" constraints bogus?

Jan Hubicka jh@suse.cz
Wed Jul 25 18:45:00 GMT 2007


> Hi,
> 
> On Wed, 25 Jul 2007, Jan Hubicka wrote:
> 
> > > > I guess we are safe now support them so I would just update the 
> > > > manual with a simple testcase so we know gimplifier does not break 
> > > > and we won't re-start emitting the warning?
> > > 
> > > Seems sensible, yes.
> > 
> > Just because it probably wasn't mentioned explicitely - the gimplifier 
> > approach is a bit weak in a sense that there is theoretically nothing 
> > explicitly keeping memory address of input and output operand the same 
> > through the compilation and in future we might invent optimizer 
> > modifying memory operands in a way that this breaks, but it seems like 
> > sane invariant to maintain for ASM operands...
> 
> For
>   asm ("", "=m" (bla) : "m" (bla))'
> any transformation which would make the address of both operands be not 
> the same (namely &bla) would be invalid.  They might be placed into 
> separate pseudo regs (or become completely different expressions, like 
> "&bla -4 + 4" and "&bla -5+5") but they have to be equal at runtime.  And 
> as long as that holds there's no problem, as reload is able to reload both 
> operands individually (by reloading the address part).  It's just when 
> they have to match that reload gets into trouble.

Well, I can imagine that in the future we might, for instance, want to
do copy propagation on memory locations as we do on register that might
result in optimizer replacing destination bla by something else
believing that the asm will read from bla and write somewhere else.
But we don't do that and many asm statements would break by such
transformation.

Honza



More information about the Gcc-patches mailing list