[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