search for: btq

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 "...

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 replace these two with a single X86_64 instruction: btq reg,25 The generated code is correct in both cases. It just isn...

...m the compiler side, where the register form is unambiguous and not questioned. The discussion we're having involves only the immediate form of the instruction. GNU as interprets: bt $63, mem as btl $63, mem which may or may not be what the user intended, but is not the same as "btq $63, mem". I'm not an official LLVM spokesperson or anything, but our consensus seems to be that "bt $imm, whatever" is ambiguous (the %eax and %rax versions you quoted disambiguate the width) and should be disallowed by the assembler. The patch we're replying to implements...

...> unambiguous and not questioned. The discussion we're having involves > only the immediate form of the instruction. GNU as interprets: > > bt $63, mem > > as > btl $63, mem > > which may or may not be what the user intended, but is not the same as > "btq $63, mem". Umm. The user doesn't care. The user wants the best code without having to worry about it. Think of it this way: the whole and ONLY point of an assembler is to make machine code reasonably easy to write, by not having to worry about the exact encoding details. We don't wan...

...And that is why I think you should just consider "bt $x,y" to be > trivially the same thing and not at all ambiguous. Because there is > ABSOLUTELY ZERO ambiguity when people write > > bt $63, mem > > Zero. Nada. None. The semantics are *exactly* the same for btl and btq > in this case, so why would you want the user to specify one or the > other? I don't think you've actually tested that, have you? (x86-64) int main() { long val = 0xffffffff; char res; asm("btl $63, %1\n\tsetc %0" : "=r"(res) : "m"(val)); prin...

...0,0x00,0x00,0x00,0x01] +btl $1, 0 // CHECK: btl $1, 0 # encoding: [0x0f,0xba,0x24,0x25,0x00,0x00,0x00,0x00,0x01] +bt $63, 0 // CHECK: btl $31, 4 # encoding: [0x0f,0xba,0x24,0x25,0x04,0x00,0x00,0x00,0x1f] +btr $63, 0 // CHECK: btrl $31, 4 # encoding: [0x0f,0xba,0x34,0x25,0x04,0x00,0x00,0x00,0x1f] +btq $63, 0 // CHECK: btq $63, 0 # encoding: [0x48,0x0f,0xba,0x24,0x25,0x00,0x00,0x00,0x00,0x3f] + // rdar://8017515 btq $0x01,%rdx // CHECK: btq $1, %rdx -- 1.8.3.2.736.g869de25

...t shifted masking bit*, and are then converted into IR as *right shifted values anded with a masking bit*. This IR then remains untouched until *Expand ISel Pseudo-instructions* in llc (-O3). At that point, *LowerToBT* is called on the REGISTER version and substitutes in a BT reg,reg instruction: btq %rsi, %rdi ## <MCInst #312 BT64rr The IMMEDIATE version doesn't match the pattern and so *LowerToBT* is not called. *Question*: This is during *pseudo instruction expansion*. How could *LowerToBT'*s caller have enough context to match the immediate IR version?...

...5 9:37 AM To: Stephen Canon Cc: LLVM Developers Mailing List Subject: Re: [LLVMdev] X86TargetLowering::LowerToBT Constant mask case. Sanjay, could you run this through the Intel compiler with the appropriate flags? They have an -O2 but I couldn't find an equivalent -Oz. For LLVM, it generates BTQ for testing bits 32-63. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150123/c72fe7bf/attachment.html>

...at cs.uiuc.edu <mailto:llvmdev at cs.uiuc.edu>> >>> >>> 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 replace these two with a single X86_64 instruction: btq r...

(Resent without HTML) On 07/14/2013 10:19 AM, Linus Torvalds wrote: > Now, there are possible cases where you want to make the size explicit > because you are mixing memory operand sizes and there can be nasty > performance implications of doing a 32-bit write and then doing a > 64-bit read of the result. I'm not actually aware of us having ever > worried/cared about it, but

...IsBitSetB_64(unsigned long long val, int index) { return (val & (1ULL<<index)) != 0ULL; } > unsigned int IsBitSetB_32(unsigned int val, int index) { return (val & (1U<<index)) != 0U; } > > $ icc -O3 -S bt.c -o - | grep bt > .file "bt.c" > btq %rsi, %rdi > btl %esi, %edi > > Does anyone at Intel have guidance for us? > > > On Thu, Jan 22, 2015 at 4:34 PM, Eric Christopher <echristo at gmail.com <mailto:echristo at gmail.com>> wrote: > > > On Thu Jan 22 2015 at 3:32:53 PM Chr...

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

...ed just fine with older versions of llvm-gcc on 32 bit Linux. FD_ZERO is defined in /usr/include/bits/select.h like this: # if __WORDSIZE == 64 # define __FD_ZERO_STOS "stosq" # define __FD_SET_BTS "btsq" # define __FD_CLR_BTR "btrq" # define __FD_ISSET_BT "btq" # else # define __FD_ZERO_STOS "stosl" # define __FD_SET_BTS "btsl" # define __FD_CLR_BTR "btrl" # define __FD_ISSET_BT "btl" # endif # define __FD_ZERO(fdsp) \ do { \ int...

> 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.

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

On Sun, Jul 14, 2013 at 5:56 AM, Ramkumar Ramachandra <artagnon at gmail.com> wrote: > 1c54d77 (x86: partial unification of asm-x86/bitops.h, 2008-01-30) > changed a bunch of btrl/btsl instructions to btr/bts, with the following > justification: > > The inline assembly for the bit operations has been changed to remove > explicit sizing hints on the instructions, so the

...D-65779 Kelkheim Fax: (+49) 6195 900600 ---------------------------------------------------------------------- ---( samba-dyn-1.9.17p1-970912.diff.gz.uu )--------------------------- begin 644 samba-dyn-1.9.17p1-970812.diff.gz M'XL("($@&30"`W-A;6)A+61Y;BTQ+CDN,3=P,2TY-S`X,3(N9&EF9@"M&FM3 MVTCRL_TK)MY=L)`,%L80(&S"@A-<%S!E.WNYRJ5<0AYC;61)I9&3D,?]]NN> M'DDCR0:275>"I>G'=/?T:V8\]68SUHJ75TPXBQNG96\?;ML'D=V*?,<+=D2X MC%V^XX?.-'+BQ;9;0JLBU%NMUB-YU5[&'AOQB-F[\.]HKWO4[3#[\/"@;IKF M@Q...

1c54d77 (x86: partial unification of asm-x86/bitops.h, 2008-01-30) changed a bunch of btrl/btsl instructions to btr/bts, with the following justification: The inline assembly for the bit operations has been changed to remove explicit sizing hints on the instructions, so the assembler will pick the appropriate instruction forms depending on the architecture and the context. Unfortunately,

...O&\'1SI?9;HU_K M7W9K&]U!LU4OOV$ENBXI"UL_E=GV[M[V[F&VNMO+!I?-T^RD<];.>OVLU>G' MZ_?Z']<>]<# #,Q$1(3FMQ":,S'V]U>G7@6).L61HT[A``[@`&$'/(P@)J71 M<G'[R"&:%3Z9V P'< `':#0T&AKM+]=HVDAVOL8G$YOA``[@`(T&/&BTQ#2: M8QP-GTQLA@,X@ ,T&O"@T9+3:,&PHA6?3&R&`SB `S:Z8Z,[)">2<YF2,RCG M6:!+B$%JP $<P &2$\F)Y$1R+E-R.F$\DI,0@]2 `SB `V:B@0>-EI9&"U*S M,PH^F=@,!W `!V@TX$&CI:71I%!2,Y"&4R8XPP$<P $B#7@0::F)-"LM(@VG M3'"&`SB `T0:\"#24A-...