Post-increment constraint in inline assembly (SuperH)

[Georg-Johann Lay]

On 29.01.2018 14:19, Oleg Endo wrote:
> On Mon, 2018-01-29 at 10:39 +0100, Georg-Johann Lay wrote:
>>   
>> Hence the source should read something like
>>
>> __asm__ ("movua.l @%1+, %0"
>>  Â Â Â Â Â Â Â Â Â Â : "=z" (longword), "+r" (src)
>>  Â Â Â Â Â Â Â Â Â Â : "m" (*src));
> 
> The problem (or rather disadvantage) with this approach is that the
> compiler doesn't know what the value of "src" is after it has been
> modified by the asm code. Â Segher's suggestion looks like the better
> option.
> 
> Cheers,
> Oleg

YMMV, I am not even sure if it is correct or even makes complete sense.

The "m>"(*src) operand doesn't even express that src is changing, and 
the constraint allows to use post-increment, but does not force it.

This means that the user cannot be sure what value src has after the asm 
(either src or src+1 w.r.t to before the asm), hence it cannot be used 
(e.g. in a loop to read several consecutive values or using several of 
these constructs in a row).

Moreover, the explicit usage of src+1 might add additional overhead; 
it's clear that the respective operation "p = src+1;" should not be 
optimized away to have an effect, but /if/ is has an effect then this 
might be an overhead (which Sébastien wanted to get rid of).  As lined 
out above, the stored value of "src+1" is of no use because the compiler 
is not forced to use post-inc, hence even if the compiler knows src 
after the asm, it's worthless to the user.

My proposal is based on experience with similar asm but for a different 
architecture, namely post-inc reads from flash on AVR: With explicit 
post-inc the compiler doesn't know the value, but that has never been a 
disadvantage with the use cases I am aware of.  But it was important for 
ME to know the value of the address after the asm in order to reuse it.

And my experience with inline asm is this: if one doesn't express all 
side effects (which is the case for "m>"(src)), then the asm will bite 
you sooner or later; even it it appeared to work fine in the past.

Johann