search for: 48b

...am not at the actual cause yet, but here is what I got so far: I have the following live ranges when I start scheduling a region: R2 = [0B,48r:0)[352r,416r:5)... R3 = [0B,48r:0)[368r,416r:5)... R4 = [0B,32r:0)[384r,416r:4)... R5 = [0B,32r:0)[400r,416r:4)... I schedule the following instruction (48B): 0B BB#0: derived from LLVM BB %entry Live Ins: %R0 %R1 %D1 %D2 8B %vreg27<def> = COPY %R1<kill>; IntRegs:%vreg27 12B %vreg30<def> = LDriw <fi#-1>, 0; mem:LD4[FixedStack-1](align=8) IntRegs:%vreg30 20B %vreg31<def> = LDriw <fi#-2>, 0; mem:LD4[FixedStack...

...got > so > far: > > I have the following live ranges when I start scheduling a region: > > R2 = [0B,48r:0)[352r,416r:5)... > R3 = [0B,48r:0)[368r,416r:5)... > R4 = [0B,32r:0)[384r,416r:4)... > R5 = [0B,32r:0)[400r,416r:4)... > > I schedule the following instruction (48B): > > 0B BB#0: derived from LLVM BB %entry > Live Ins: %R0 %R1 %D1 %D2 > 8B %vreg27<def> = COPY %R1<kill>; IntRegs:%vreg27 > 12B %vreg30<def> = LDriw <fi#-1>, 0; > mem:LD4[FixedStack-1](align=8) IntRegs:%vreg30 >...

...am not at the actual cause yet, but here is what I got so far: I have the following live ranges when I start scheduling a region: R2 = [0B,48r:0)[352r,416r:5)... R3 = [0B,48r:0)[368r,416r:5)... R4 = [0B,32r:0)[384r,416r:4)... R5 = [0B,32r:0)[400r,416r:4)... I schedule the following instruction (48B): 0B BB#0: derived from LLVM BB %entry Live Ins: %R0 %R1 %D1 %D2 8B %vreg27<def> = COPY %R1<kill>; IntRegs:%vreg27 12B %vreg30<def> = LDriw <fi#-1>, 0; mem:LD4[FixedStack-1](align=8) IntRegs:%vreg30 20B %vreg31<def&gt...

...I got so > far: > > I have the following live ranges when I start scheduling a region: > > R2 = [0B,48r:0)[352r,416r:5)... > R3 = [0B,48r:0)[368r,416r:5)... > R4 = [0B,32r:0)[384r,416r:4)... > R5 = [0B,32r:0)[400r,416r:4)... > > I schedule the following instruction (48B): > > 0B BB#0: derived from LLVM BB %entry > Live Ins: %R0 %R1 %D1 %D2 > 8B %vreg27<def> = COPY %R1<kill>; IntRegs:%vreg27 > 12B %vreg30<def> = LDriw <fi#-1>, 0; > mem:LD4[FixedStack-1](align=8) IntRegs:%vreg30 > 20B %vreg31<def> = LDriw &...

...am not at the actual cause yet, but here is what I got so far: I have the following live ranges when I start scheduling a region: R2 = [0B,48r:0)[352r,416r:5)... R3 = [0B,48r:0)[368r,416r:5)... R4 = [0B,32r:0)[384r,416r:4)... R5 = [0B,32r:0)[400r,416r:4)... I schedule the following instruction (48B): 0B BB#0: derived from LLVM BB %entry Live Ins: %R0 %R1 %D1 %D2 8B %vreg27<def> = COPY %R1<kill>; IntRegs:%vreg27 12B %vreg30<def> = LDriw <fi#-1>, 0; mem:LD4[FixedStack-1](align=8) IntRegs:%vreg30 20B %vreg31<def&gt...

...gt; I have the following live ranges when I start scheduling a region: >> >> R2 = [0B,48r:0)[352r,416r:5)... >> R3 = [0B,48r:0)[368r,416r:5)... >> R4 = [0B,32r:0)[384r,416r:4)... >> R5 = [0B,32r:0)[400r,416r:4)... >> >> I schedule the following instruction (48B): >> >> 0B BB#0: derived from LLVM BB %entry >> Live Ins: %R0 %R1 %D1 %D2 >> 8B %vreg27<def> = COPY %R1<kill>; IntRegs:%vreg27 >> 12B %vreg30<def> = LDriw <fi#-1>, 0; >> mem:LD4[FixedStack-1](align=8) IntR...

On Aug 28, 2012, at 8:18 AM, Sergei Larin <slarin at codeaurora.org> wrote: > > I've described that issue (see below) when you were out of town... I think > I am getting more context on it. Please take a look... > > So, in short, when the new MI scheduler performs move of an instruction, it > does something like this: > > // Move the instruction to its new

...constant. It transforms 0B BB#0: derived from LLVM BB %entry 16B %vreg0<def> = MOV64rm %RIP, 1, %noreg, <ga:@val>[TF=5], %noreg; mem:LD8[GOT] GR64:%vreg0 32B %vreg1<def> = MOV64rm %RIP, 1, %noreg, <ga:@p>[TF=5], %noreg; mem:LD8[GOT] GR64:%vreg1 48B MOV64mr %vreg1, 1, %noreg, 0, %noreg, %vreg0; mem:ST8[@p](tbaa=!"any pointer") GR64:%vreg1,%vreg0 64B %vreg2<def> = MOV64ri 12345123400; GR64:%vreg2 80B MOV64mr %vreg0, 1, %noreg, 0, %noreg, %vreg2; mem:ST8[@val](tbaa=!"long long") GR64:...

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

For the little C test program where a constant is stored in memory and also used as a parameter: #include <stdint.h> uint64_t val, *p; extern uint64_t xtr( uint64_t); uint64_t caller() { uint64_t x; p = &val; x = 12345123400L; *p = x; return xtr(x); } clang (3.2, 3.3 and svn) generates the following X86 code (at -O3): caller: movq

...0B BB#0: derived from LLVM BB %entry > 16B %vreg0<def> = MOV64rm %RIP, 1, %noreg, > <ga:@val>[TF=5], %noreg; mem:LD8[GOT] GR64:%vreg0 > 32B %vreg1<def> = MOV64rm %RIP, 1, %noreg, <ga:@p>[TF=5], > %noreg; mem:LD8[GOT] GR64:%vreg1 > 48B MOV64mr %vreg1, 1, %noreg, 0, %noreg, %vreg0; > mem:ST8[@p](tbaa=!"any pointer") GR64:%vreg1,%vreg0 > 64B %vreg2<def> = MOV64ri 12345123400; GR64:%vreg2 > 80B MOV64mr %vreg0, 1, %noreg, 0, %noreg, %vreg2; > mem:ST8[@val](tbaa=!"lo...

...s when I start scheduling a region: > >> > >> R2 = [0B,48r:0)[352r,416r:5)... > >> R3 = [0B,48r:0)[368r,416r:5)... > >> R4 = [0B,32r:0)[384r,416r:4)... > >> R5 = [0B,32r:0)[400r,416r:4)... > >> > >> I schedule the following instruction (48B): > >> > >> 0B BB#0: derived from LLVM BB %entry > >> Live Ins: %R0 %R1 %D1 %D2 > >> 8B %vreg27<def> = COPY %R1<kill>; IntRegs:%vreg27 > >> 12B %vreg30<def> = LDriw <fi#-1>, 0; > >> mem:L...

...her the containing function's PGO cold attribute is set. If either are true it emits BT for tests of bits 8-31 instead of TEST. Previously, TEST was always used for bits 0-31 and BT was always used for bits 32-63. Since the BT instruction is 16b smaller than TEST for the bits 8-31 case, 32b vs 48b, and not irredeemably slower, it makes sense to use BT in cases where size matters. Similar logic is possible for BTC and BTS. However, LowerToBTC and LowerToBTS would need to be written and used and that's a larger patch. -------------- next part -------------- An HTML attachment was scrubbed...

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 isn't supposed to affect the runtime as much as this is going to. -eric...

On Aug 30, 2012, at 1:20 PM, Arnold Schwaighofer <arnolds at codeaurora.org> wrote: > The code in collectRanges() does: > > // Collect ranges for register units. These live ranges are computed on > // demand, so just skip any that haven't been computed yet. > if (TargetRegisterInfo::isPhysicalRegister(Reg)) { > for (MCRegUnitIterator Units(Reg,

...got > so > far: > > I have the following live ranges when I start scheduling a region: > > R2 = [0B,48r:0)[352r,416r:5)... > R3 = [0B,48r:0)[368r,416r:5)... > R4 = [0B,32r:0)[384r,416r:4)... > R5 = [0B,32r:0)[400r,416r:4)... > > I schedule the following instruction (48B): > > 0B BB#0: derived from LLVM BB %entry > Live Ins: %R0 %R1 %D1 %D2 > 8B %vreg27<def> = COPY %R1<kill>; IntRegs:%vreg27 > 12B %vreg30<def> = LDriw <fi#-1>, 0; > mem:LD4[FixedStack-1](align=8) IntRegs:%vreg30 >...

...8010, OldIdx=..., Internal=...) at > lib/CodeGen/LiveIntervalAnalysis.cpp:1226 > #7 in llvm::LiveIntervals::HMEditor::moveAllRangesFrom > (this=0x7fffffff8010, MI=0x462ab80, OldIdx=...) at > lib/CodeGen/LiveIntervalAnalysis.cpp:938 > #8 in llvm::LiveIntervals::handleMove (this=0x448b6f0, MI=0x462ab80) > at > lib/CodeGen/LiveIntervalAnalysis.cpp:1388 > #9 in llvm::VLIWMachineScheduler::moveInstruction (this=0x46b0f50, > MI=0x462ab80, InsertPos=...) at > lib/Target/Hexagon/HexagonMachineScheduler.cpp:120 > #10 in llvm::VLIWMachineScheduler::schedule (this=0x...

...ddproddivConst: Post SSA Function Live Ins: %FA_ROFF1 in %vreg0 0B BB#0: derived from LLVM BB %entry Live Ins: %FA_ROFF1 16B %vreg0<def> = COPY %FA_ROFF1; FPUaOffsetClass:%vreg0 32B %vreg2<def> = MOVSUTO_A_iSLo 1077936128; FPUaOffsetClass:%vreg2 48B %vreg3<def> = FMUL_A_oo %vreg0, %vreg2, %RFLAGA<imp-def,dead>; FPUaROUTMULRegisterClass:%vreg3 FPUaOffsetClass:%vreg0,%vreg2 64B %vreg4<def> = COPY %vreg3; FPUaOffsetClass:%vreg4 FPUaROUTMULRegisterClass:%vreg3 80B %vreg5<def> = MOVSUTO_A_...

The code in collectRanges() does: // Collect ranges for register units. These live ranges are computed on // demand, so just skip any that haven't been computed yet. if (TargetRegisterInfo::isPhysicalRegister(Reg)) { for (MCRegUnitIterator Units(Reg, &TRI); Units.isValid(); ++Units) if (LiveInterval *LI = LIS.getCachedRegUnit(*Units))

...k3foos: Post SSA Frame Objects: fi#-1: size=2, align=2, fixed, at location [SP+50] Function Live Ins: %X3 in %vreg1, %X4 in %vreg2 0B BB#0: derived from LLVM BB %entry Live Ins: %X3 %X4 16B %vreg2<def> = COPY %X4; G8RC_with_sub_32:%vreg2 32B %vreg1<def> = COPY %X3; G8RC:%vreg1 48B STH8 %vreg1<kill>, 0, <fi#-1>; mem:ST2[FixedStack-1] G8RC:%vreg1 64B %vreg4<def> = LHA 0, <fi#-1>; mem:LD2[%0] GPRC:%vreg4 ... --------------------------------------------------------------- So far, so good. When we get to list scheduling, not quite so go...