llvm dev - Feb 2014 - [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

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>

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.

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.

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?

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 ());