reed kotler
2014-Feb-21 19:12 UTC
[LLVMdev] interesting LLVM code optimization issue regarding timer registers
This problem was reported to me by a friend who has an LLVM port that is not put back to open source. Essentially, there is an intrinsic call _lr which is a load register. so then user code has something like: start_time = _lr(TIMER_REGISTER) ..... some_code_to_time .... end_time = _lr(TIMER_REGISTER) So what happens is that LLVM moves the code as follows: start_time = _lr(TIMER_REGISTER) end_time = _lr(TIMER_REGISTER) ..... some_code_to_time ...... How would this intrinsic be implemented properly in llvm so this cannot happen? TIA. Reed
Francois Pichet
2014-Feb-21 19:22 UTC
[LLVMdev] interesting LLVM code optimization issue regarding timer registers
I vaguely remember having the same problem... Removing [IntrNoMem] on the intrinsic fixed it. On Fri, Feb 21, 2014 at 2:12 PM, reed kotler <rkotler at mips.com> wrote:> This problem was reported to me by a friend who has an LLVM port that is > not put back to open source. > > Essentially, there is an intrinsic call _lr which is a load register. > > so then user code has something like: > > start_time = _lr(TIMER_REGISTER) > ..... > some_code_to_time > .... > end_time = _lr(TIMER_REGISTER) > > So what happens is that LLVM moves the code as follows: > > > > start_time = _lr(TIMER_REGISTER) > end_time = _lr(TIMER_REGISTER) > ..... > some_code_to_time > ...... > > How would this intrinsic be implemented properly in llvm so this cannot > happen? > > TIA. > > Reed > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140221/35cbad67/attachment.html>
Tim Northover
2014-Feb-21 19:24 UTC
[LLVMdev] interesting LLVM code optimization issue regarding timer registers
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.
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.
James Courtier-Dutton
2014-Feb-22 08:43 UTC
[LLVMdev] interesting LLVM code optimization issue regarding timer registers
On 21 February 2014 19:12, reed kotler <rkotler at mips.com> wrote:> This problem was reported to me by a friend who has an LLVM port that is not > put back to open source. > > Essentially, there is an intrinsic call _lr which is a load register. > > so then user code has something like: > > start_time = _lr(TIMER_REGISTER) > ..... > some_code_to_time > .... > end_time = _lr(TIMER_REGISTER) > > So what happens is that LLVM moves the code as follows: > > > > start_time = _lr(TIMER_REGISTER) > end_time = _lr(TIMER_REGISTER) > ..... > some_code_to_time > ...... > > How would this intrinsic be implemented properly in llvm so this cannot > happen? >Is compiling with -O0 acceptable here? Probably not if you want "some_code_to_time" to be optimized with LLVM. Is "_Ir(TIMER_REGISTER)" being set as volatile?
James Courtier-Dutton
2014-Feb-26 10:11 UTC
[LLVMdev] interesting LLVM code optimization issue regarding timer registers
On 21 February 2014 19:12, reed kotler <rkotler at mips.com> wrote:> This problem was reported to me by a friend who has an LLVM port that is not > put back to open source. > > Essentially, there is an intrinsic call _lr which is a load register. > > so then user code has something like: > > start_time = _lr(TIMER_REGISTER) > ..... > some_code_to_time > .... > end_time = _lr(TIMER_REGISTER) > > So what happens is that LLVM moves the code as follows: > > > > start_time = _lr(TIMER_REGISTER) > end_time = _lr(TIMER_REGISTER) > ..... > some_code_to_time > ...... > > How would this intrinsic be implemented properly in llvm so this cannot > happen? > > TIA. > > Reed >Do we need something equivalent to gcc's emit_insn (gen_blockage ());
Maybe Matching Threads
- [LLVMdev] interesting LLVM code optimization issue regarding timer registers
- How to add a barrier pseudo instruction?
- New intrinsic property IntrOnlyWrite
- Clarification to man upssched.conf
- Re: [PATCH v3 1/4] mltools: Rename Yajl module as JSON_parser and move to common/mltools.