[LLVMdev] interesting LLVM code optimization issue regarding timer registers
Philip Reames
listmail at philipreames.com
Mon Feb 24 13:37:32 PST 2014
On 02/22/2014 12:17 AM, Tim Northover wrote:
>> THe dsp instruction has no side effects and does not access memory.
>>
>> It's a valid thing to do.
> At's a sympathetic desire, but doesn't fit entirely well with what the
> compiler's doing. Associated with tha DSP instruction are likely to be
> argument marshalling COPYs, and it's not entirely clear what semantics
> they should have w.r.t. moving past the timer (even in an ideal
> world).
>
> Regardless, I don't think LLVM has that level of "keep your hands off" hints.
If it doesn't, we really need to consider adding them. Essentially, the
read of a timer register here is a stand-in for any unmodelled side
effect. There are lots of other cases where this arises as well:
- changing the floating point context
- changing control registers of most any variety (including ones which
effect the behaviour of the instruction in question!)
- touching a potentially faulting page (to trigger a known trap)
- unwinding the stack
Having the ability to model a function with potentially arbitrary side
effects is necessary.
Just to be clear, I'm not suggesting that the most conservative
modelling needs to be the default. Frankly, I think it should be, but
I'm open to arguments about that not being the specified behaviour for
the languages we primarily target. Having said that, we definitely need
the ability to represent more conservative semantics - both for existing
C/C++ code and to correctly support other languages.
Philip
More information about the llvm-dev
mailing list