llvm dev - Jun 2015 - [LLVMdev] Prevent instruction selection from clobbering an implicit data dependence through flags?

Hi,

In my target, certain intrinsic functions read or write the machine's flag
registers.  Some of my benchmarks rely on implicit data dependences among such
intrinsics.  How can I specify that these intrinsics carry this dependence, and
that this dependence should be preserved through instruction selection?

For example, suppose I have this snippet of IR:
   ; (i) Write to flags
   tail call void @llvm.desradgcv2.mtcsr.n..s.i(i32 %written, i32 14)
   ; (ii) Some instructions in between
   %c = add i32 %a, %b
   %d = sub i32 0, %c
   ; (iii) Read from flags, i.e, %read := %written
   %read = tail call i32 @llvm.desradgcv2.mfcsr.s..i(i32 14)

During instruction selection, a pattern selects the 'mtcsr' and
'mfcsr' instructions for the two intrinsic calls (i) and (iii),
respectively. There are two choices for the instructions in the middle (ii):
1. A verbatim translation into an 'add' and a 'sub' instruction.
I prefer this because it does not modify the flags in question.
2. The more idiomatic translation into 'negadd'.  In this context, this
translation is incorrect because it clobbers the flag and disrupts the data
dependence from (i) to (iii).

How can I specify that the second choice is incorrect in this instance because
it clobbers the implicit flow.

Thank you,
Nick Johnson
D. E. Shaw Research

Hi Nick,

At the present time, unfortunately, LLVM only understands memory dependencies.
You'll need to mark your intrinsics that write to the flags register as
writing to memory, and those that read from the register as reading from memory.
Not the best solution possible, but it will work. You might also add logic in
BasicAA, etc. to eliminate unnecessary MayAlias decisions (much like how
@llvm.assume is handled).

 -Hal

----- Original Message -----
> From: "Nicholas Paul Johnson" <Nicholas.Paul.Johnson at
DEShawResearch.com>
> To: llvmdev at cs.uiuc.edu
> Sent: Friday, June 12, 2015 9:47:59 AM
> Subject: [LLVMdev] Prevent instruction selection from clobbering an
implicit data dependence through flags?
> 
> Hi,
> 
> In my target, certain intrinsic functions read or write the machine's
> flag registers.  Some of my benchmarks rely on implicit data
> dependences among such intrinsics.  How can I specify that these
> intrinsics carry this dependence, and that this dependence should be
> preserved through instruction selection?
> 
> For example, suppose I have this snippet of IR:
>    ; (i) Write to flags
>    tail call void @llvm.desradgcv2.mtcsr.n..s.i(i32 %written, i32 14)
>    ; (ii) Some instructions in between
>    %c = add i32 %a, %b
>    %d = sub i32 0, %c
>    ; (iii) Read from flags, i.e, %read := %written
>    %read = tail call i32 @llvm.desradgcv2.mfcsr.s..i(i32 14)
> 
> During instruction selection, a pattern selects the 'mtcsr' and
> 'mfcsr' instructions for the two intrinsic calls (i) and (iii),
> respectively. There are two choices for the instructions in the
> middle (ii):
> 1. A verbatim translation into an 'add' and a 'sub'
instruction.  I
> prefer this because it does not modify the flags in question.
> 2. The more idiomatic translation into 'negadd'.  In this context,
> this translation is incorrect because it clobbers the flag and
> disrupts the data dependence from (i) to (iii).
> 
> How can I specify that the second choice is incorrect in this
> instance because it clobbers the implicit flow.
> 
> Thank you,
> Nick Johnson
> D. E. Shaw Research
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory

Thanks, Hal, for the quick reply. 

From: Hal Finkel
>You'll need to mark your intrinsics that write to the flags
>register as writing to memory, and those that read from the register as
>reading from memory. Not the best solution possible, but it will work.
I see how marking the intrinsics as IntrMem and IntrReadMem would prevent the
scheduler from re-ordering these instructions before and during selection.

However with respect to my example, it's not clear how this would prevent
the selector from choosing the 'negadd' instruction and thereby
clobbering the flags.

>might also add logic in BasicAA, etc. to eliminate unnecessary MayAlias
>decisions (much like how @llvm.assume is handled).
>
A very good point! Thanks,

Nick Johnson
D. E. Shaw Research
>----- Original Message -----
>> From: "Nicholas Paul Johnson"
><Nicholas.Paul.Johnson at DEShawResearch.com>
>> To: llvmdev at cs.uiuc.edu
>> Sent: Friday, June 12, 2015 9:47:59 AM
>> Subject: [LLVMdev] Prevent instruction selection from clobbering an
>implicit data dependence through flags?
>>
>> Hi,
>>
>> In my target, certain intrinsic functions read or write the
machine's
>> flag registers.  Some of my benchmarks rely on implicit data
>> dependences among such intrinsics.  How can I specify that these
>> intrinsics carry this dependence, and that this dependence should be
>> preserved through instruction selection?
>>
>> For example, suppose I have this snippet of IR:
>>    ; (i) Write to flags
>>    tail call void @llvm.desradgcv2.mtcsr.n..s.i(i32 %written, i32 14)
>>    ; (ii) Some instructions in between
>>    %c = add i32 %a, %b
>>    %d = sub i32 0, %c
>>    ; (iii) Read from flags, i.e, %read := %written
>>    %read = tail call i32 @llvm.desradgcv2.mfcsr.s..i(i32 14)
>>
>> During instruction selection, a pattern selects the 'mtcsr' and
>> 'mfcsr' instructions for the two intrinsic calls (i) and (iii),
>> respectively. There are two choices for the instructions in the
>> middle (ii):
>> 1. A verbatim translation into an 'add' and a 'sub'
instruction.  I
>> prefer this because it does not modify the flags in question.
>> 2. The more idiomatic translation into 'negadd'.  In this
context,
>> this translation is incorrect because it clobbers the flag and
>> disrupts the data dependence from (i) to (iii).
>>
>> How can I specify that the second choice is incorrect in this
>> instance because it clobbers the implicit flow.
>>
>> Thank you,
>> Nick Johnson
>> D. E. Shaw Research
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
>--
>Hal Finkel
>Assistant Computational Scientist
>Leadership Computing Facility
>Argonne National Laboratory