[llvm-commits] [llvm] r160117 - in /llvm/trunk: include/llvm/IntrinsicsX86.td lib/Target/X86/X86ISelLowering.cpp lib/Target/X86/X86ISelLowering.h lib/Target/X86/X86InstrInfo.td test/CodeGen/X86/rdrand.ll

[Benjamin Kramer]

On 12.07.2012, at 19:35, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote:

> 
> On Jul 12, 2012, at 10:26 AM, Benjamin Kramer <benny.kra at gmail.com> wrote:
> 
>> 
>> On 12.07.2012, at 18:53, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote:
>> 
>>> 
>>> On Jul 12, 2012, at 2:31 AM, Benjamin Kramer <benny.kra at googlemail.com> wrote:
>>> 
>>>> Author: d0k
>>>> Date: Thu Jul 12 04:31:43 2012
>>>> New Revision: 160117
>>>> 
>>>> URL: http://llvm.org/viewvc/llvm-project?rev=160117&view=rev
>>>> Log:
>>>> Add intrinsics for Ivy Bridge's rdrand instruction.
>>>> 
>>>> The rdrand/cmov sequence is the same that is emitted by both
>>>> GCC and ICC.
>>> 
>>> Hi Ben,
>>> 
>>> You should make sure we don't CSE these instructions:
>>> 
>>> define i32 @f() nounwind {
>>> entry:
>>> %0 = tail call { i32, i32 } @llvm.x86.rdrand.32() nounwind
>>> %1 = extractvalue { i32, i32 } %0, 0
>>> %2 = tail call { i32, i32 } @llvm.x86.rdrand.32() nounwind
>>> %3 = extractvalue { i32, i32 } %2, 0
>>> %add = add i32 %3, %1
>>> ret i32 %add
>>> }
>>> 
>>> $ llc -mattr=+rdrand < rdrand.ll
>>> f:                                      # @f
>>> # BB#0:                                 # %entry
>>> 	rdrandl	%eax
>>> 	addl	%eax, %eax
>>> 	ret
>> 
>> Hmm, I thought I hit all knobs to make sure all CSE passes know to avoid rdrand. What is the right way to teach MachineCSE the same thing? SDNPSideEffect? Should the RDRAND node have a chain?
> 
> The MachineLICM and MachineCSE passes will leave instructions alone if MCID::UnmodeledSideEffects is set. Set hasSideEffects = 1 in the instruction description.
> 
> But I think you should give the RDRAND node a chain as well. We really don't want to be clever about reordering these intrinsics since their primary purpose is security software.

The instruction now has side effects and a chain with r160137.

The amusing part is that gcc 4.7 has the same bug so I carefully tested it, but apparently didn't have the right test case to trigger MachineLICM.

- Ben