reed kotler
2014-Feb-21 19:39 UTC
[LLVMdev] interesting LLVM code optimization issue regarding timer registers
He has tried this and it does not solve the problem. The problem is that someone wants to, for example, time a dsp instruction. THe dsp instruction has no side effects and does not access memory. It's a valid thing to do. Should be some way to do this I would think. Tia. Reed On 02/21/2014 11:24 AM, Tim Northover wrote:> Hi Reed, > >> How would this intrinsic be implemented properly in llvm so this cannot >> happen? > At the intrinsic level, you'd make sure @llvm.whatever had the most > side-effecty definition possible (I think it's actually the default: > "this may read or write completely random memory wherever it feels > like"). > > At the instruction level, you'd make sure hasSideEffects=1 was set. > > Theoretically, a completely side-effect-free sequence of instructions > might still be moved around, but you're almost certainly Doing It > Wrong if that affects you: LLVM is always going to be able to insert > COPYs, spills and various other bits in there that you didn't write > down. > > Cheers. > > Tim.
Tim Northover
2014-Feb-22 08:17 UTC
[LLVMdev] interesting LLVM code optimization issue regarding timer registers
> 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.> Should be some way to do this I would think.If I really wanted that degree of control I'd put the whole lot into an inline assembly block. Sorry I couldn't suggest anything neater. Tim.
Philip Reames
2014-Feb-24 21:37 UTC
[LLVMdev] interesting LLVM code optimization issue regarding timer registers
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