Hi, On Thu, 27 Feb 2014, Richard Sandiford wrote:
> [... many cases where 'volatile' in asm doesn't inhibit optimizations > ...] > > We do nothing this draconian for a normal function call, which could > easily use a volatile asm internally. IMO anything that isn't flushed > for a call shouldn't be flushed for a volatile asm either. My view was always that the only semantic meaning of 'volatile' in a new style asm was that it's not going to be optimized away, even if all obvious outputs from the constraints were dead. Or IOW, that volatile can have more side-effects than described by the constraints doesn't give leeway to the asms author to wreak havoc on the machine (and in particular change the runtime environment in which other instructions are executed). I think that also matches the current inline asm docu, which always mentions 'volatile asm' in connection with not removing it. It also mentions "important side-effect", but I think changing machine state in such way as to change interpretations of register content doesn't count as side effect. That's like changing the stack pointer in a volatile asm. If machine-state changing side-effects would be allowed in volatile asms, then I'd claim that changing the stack pointer should be allowed as well (it's just a register, right?). And that's obvious bollocks. (machine state changes are of course okay, if the author expects them and takes proper precautions) > One of the big grey areas is what should happen for floating-point ops > that depend on the current rounding mode. That isn't really modelled > properly yet though. Again, it affects calls as well as volatile asms. Right, which is why we should not talk about floating point control with respect to volatile asms. _Nothing_ related to FPC is there ;) Ciao, Michael.
