------- Comment #39 from michaelni at gmx dot at 2007-02-27 22:50 -------
(In reply to comment #38)
> (In reply to comment #37)
> > now if there is a unwritten rule that "m" operands and variations of them
> > cannot be copied anywhere, then it would be very desireable to have a asm
> > constraint like "m" without this restriction this would resolve this and
> > several other bugs
> > also it would be very nice if such a dont copy restriction on "m" if it does
> > exist could be documented
>
> Copying "m" operands onto the stack might not be such a great thing to wish
> for. Imagine if you used asm("movaps %xmm0, %0": "=m"(x[i])); If x[i] is
> only
> 32-bits, and gcc copied it onto the stack, then writing 16 bytes with movaps
> wouldn't also write to x[i+1] to x[i+3] as intended. I know there is a plenty
> of asm code in ffmpeg that overwrites or overreads memory operands and will
> fail if gcc tried to move them onto the stack. There is also alignment.
> movaps requires an aligned address, and maybe you have chosen x and i in such
> a
> way that it will be aligned. But when gcc copies the value onto the stack,
> how
> is it supposed to know what alignment it needs?
well the data type used in "m"() must of course be correct, that is here a
128bit type, alignment can be handled like with all other types, double also
gets aligned if the architecture needs it, so a uint128_t or sse128 or whatever
can as well, the example you show is a fairly obscure special case in respect
to moving "m" to the stack, in the end theres a need for a "m" like constraint
which must not be moveable and a "m" like constraint which should be moveable
(to the stack for example) the exact letters used are irrelevant
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203
