similar to: [LLVMdev] X86TargetLowering::LowerToBT

tst64.ll is attached from clang -S -emit-llvm tst64.c On Sat, Jan 24, 2015 at 11:56 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > Can you transform you C file into a LLVM IR lit test? > > See example in test/CodeGen/X86/*.ll > > Thanks, > > Mehdi > > > On Jan 24, 2015, at 11:47 AM, Chris Sears <chris.sears at gmail.com> wrote: > > > >

Sure. Attached is the file but here are the functions. The first uses a fixed bit offset. The second has a indexed bit offset. Compiling with llc -O3, LLVM version 3.7.0svn, it compiles the IR from IsBitSetB() using btq %rsi, %rdi. Good. But then it compiles IsBitSetA() with shrq/andq, which is is pretty much what Clang had generated as IR. shrq $25, %rdi andq $1, %rdi LLVM should be able to

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

I'm tracking down an X86 code generation malfeasance regarding BT (bit test) and I have some questions. This IR *matches* and then *X86TargetLowering::LowerToBT **is called:* %and = and i64 %shl, %val * ; (val & (1 << index)) != 0 ; *bit test with a *register* index This IR *does not match* and so *X86TargetLowering::LowerToBT **is not called:* %and = lshr i64 %val, 25

> On Jan 22, 2015, at 1:22 PM, Fiona Glaser <fglaser at apple.com> wrote: > > According to Agner’s docs, many CPUs have slower BT than TEST; Haswell has only 0.5 inverse throughput as opposed to 0.25, Atom has 1 instead of 0.5, and Silvermont can’t even dual-issue BT (it locks both ALUs). So while BT does seem have a shorter instruction encoding than TEST for TEST reg, imm32 where

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

I’ll be happy to run it for you. Do you want Intel64, x86 or both? The Intel compiler doesn’t have a –Oz option. It has –Os and –O[123]. Also, FWIW, one of the Intel compiler experts on BT will comment on this thread, and on our rules for BT usage later this afternoon. Kevin B. Smith From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Chris Sears Sent:

Yeah, the alternative is to do movabs and then test, which is doable but I’m not sure if it’s worth it (surely BT + risk of flags merging penalty has to be better than two ops, one of which is ~9-10 bytes). Fiona > On Jan 22, 2015, at 2:59 PM, Chris Sears <chris.sears at gmail.com> wrote: > > My bad on that. So that's what the comment meant. > That means BT is pretty much

On Thu Jan 22 2015 at 3:32:53 PM Chris Sears <chris.sears at gmail.com> wrote: > The status quo is: > > a) 40b REX+BT instruction for the 64b case > b) 48b TEST for the 32b case > c) unless it's small TEST > > > You are currently paying a 16b penalty for TEST vs BT in the 32b case. > That may be worth testing the -Os flag. > You'll want -Oz here, Os

Which BTQ? There are three flavors. BTQ reg/reg BTQ reg/mem BTQ reg/imm I can imagine that the reg/reg and especially the reg/mem versions would be slow. However the shrq/and versions *with the same operands* would be slow as well. There's even a compiler comment about the reg/mem version saying "this is for disassembly only". But I doubt BTQ reg/imm would be microcoded. -- Ite

I suspect that this is because the mask in your example is the result of a variable shift, which (a) has it’s own performance and flags hazards pre-SHLX and (b) requires additional µops to do with TEST. I expect that ICC is putting a dummy TEST or XOR ahead of the BT to break the false flags dependency, as well. If the mask were constant, I expect ICC would generate TEST instead (but I don’t

> icc generates testq for 0-30 and btq for 31-63. > That seems like a small bug in the bit 31 case. You can’t use testq for bit 31, because the immediate gets sign-extended. You *can* use the 32b form, of course.

In file lib/Target/X86/X86ISelLowering.cpp Function X86TargetLowering::getRegClassForInlineAsmConstraint I think the second register must be X86::BL. else if (VT == MVT::i8) return make_vector<unsigned>(X86::AL, X86::DL, X86::CL, X86::DL, 0); Lauro -------------- next part -------------- An HTML attachment was scrubbed... URL:

I've had a bug/pessimization which I've tracked down for 1 bit bitmasks: if (((xx) & (1ULL << (40)))) return 1; if (!((yy) & (1ULL << (40)))) ... The second time Constant Hoisting sees the value (1<<40) it wraps it up with a bitcast. That value then gets hoisted. However, the first (1<<40) is not bitcast and gets recognized as a BT. The second

I have a dataframe zeespan. One of the columns has the name "customer". The data in the customer column is text. I would like to return a subset of the dataframe with all rows that DON'T begin with either "ibm" or "exxon", or "sears" in the customer column. I tried .... subset(zeespan, customer != c("ibm" | "exxon" |

I'd like to store a tablegen generated enumeration in a record field/value. Clearly this enumeration isn't available yet so it seems that a code fragment should be the escape mechanism I need. Looking at the other backends for examples, I see things like [{ return Imm >= 0 && Imm < 64; }] // promising code Requires = [{ {} }];

Hey Everyone, I downloaded and installed the X-Lite softphone the other day (the lite version) and cannot seem to get it to work well. Don't get me wrong, it registers with my asterisk server and everything seems to work well, except the call quality really is horrible. I thought it may be the place I was trying it at (DSL) so I took it to the office and tried it right next to the asterisk

Hey Everyone, I am using NuFone for 866 inbound service and I am trying to figure out the callerid part of it. Any call into my * system just shows "Toll Free Call" and will not give me the calling party's caller ID info. Is this just something I have to live with using NuFOne, or did I miss some type of config in * that will grab the callerID other than the inbound 866 number...?

Hello R Experts, How can I assign the name of a data frame with the argument of a function? Specifically I am using RODBC to build local dataframes from SAS datasets on a remote server. I would like the local dataframe have the same name as the source SAS dataset, and the function below is what I am developing. However, the "substitute(table)" on the left side of the assignment

Hi Chris, If you have everything setup to test, can you generate the LLVM IR with -03 from 3.4.1 and 3.5 to be sure they match. Then we can focus on the backend. Thanks, Mehdi > On Feb 3, 2015, at 1:58 AM, Chris Sears <chris.sears at gmail.com> wrote: > > So between 3.4.1 and 3.5 since it isn't in 3.4.1 and it is in the current XCode. -------------- next part