llvm dev - Jan 2015 - [LLVMdev] X86TargetLowering::LowerToBT

That’s not how partial-flags update stalls work.  There is no independent
tracking of individual bits in EFLAGS.  This means that BT + CMOVNZ has a false
dependency on whatever instruction wrote to EFLAGS before BT and requires an
extra µop vis-a-vis TEST + CMOVNZ or SHR + AND.

Please do not use BT.  It is a performance hazard.  If you don’t believe me for
some reason, here’s the relevant quote from Agner:

"BT, BTC, BTR, and BTS change the carry flag but leave the other flags
unchanged. This causes a false dependence on the previous value of the flags and
costs an extra μop. Use TEST, AND, OR and XOR instead of these instructions.”

– Steve
> On Jan 22, 2015, at 5:05 PM, Chris Sears <chris.sears at gmail.com>
wrote:
> 
> I think the partial update issue isn't really valid concern, Agner
Fogg, p 142. I don't think LLVM is going to emit this fragment.
> 
> ; Example 10.7. Partial register access
> bt eax,2 ; modifies carry flag but not zero flag
> cmovbe eax,ebx ; reads both carry flag and zero flag
> 
> In cases like this, you may consider whether it is a programming error or a
deliberate testing of two different conditions with a single instruction.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

The problem is that REX TEST reg,#(1<<37) is 10 bytes vs 5 bytes for REX
BT
reg,37.
That's a large space penalty to pay for a possible partial update stall.

So the idea of generating BT for -Os and TEST for -Ofast makes sense to me.
Regardless, LowerToBT is generating TEST for small values.

I'm still tracking down the Clang issue and I'd like folks to look at
that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150122/874b4633/attachment.html>

Is that even a valid instruction? I thought TEST only took 32-bit immediates.

Fiona
> On Jan 22, 2015, at 2:48 PM, Chris Sears <chris.sears at gmail.com>
wrote:
> 
> The problem is that REX TEST reg,#(1<<37) is 10 bytes vs 5 bytes for
REX BT reg,37.
> That's a large space penalty to pay for a possible partial update
stall.
> 
> So the idea of generating BT for -Os and TEST for -Ofast makes sense to me.
> Regardless, LowerToBT is generating TEST for small values.
> 
> I'm still tracking down the Clang issue and I'd like folks to look
at that.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev