search for: reg1026

...scalar_to_vector 0x391ac10 srcLineNum= 10 > 0x3927b10: <multiple use> > 0x3923100: v2f64 = vector_shuffle 0x391c970, 0x391c8b0, > 0x3927b10<0,2> srcLineNum= 10 > > The code that gets produced looks like this: > > %reg1071<def> = MOVSD2PDrm %reg1026, 8, %reg1065, 4294967288, Mem:LD(8,8) > [r66428 + 0]LD(8,8) [r78427 + 0] ; srcLine 10 > %reg1072<def> = MOVSD2PDrm %reg1026, 8, %reg1065, 4294967288, Mem:LD(8,8) > [r66428 + 0]LD(8,8) [r78427 + 0] ; srcLine 10 > %reg1073<def> = SHUFPDrri %reg1071, %reg1072, 0 ; srcLine...

...or _Z3addii(): <fi #-2> is 4 bytes fixed at location [SP-20] <fi #-1> is 4 bytes fixed at location [SP-16] entry (0x8681458): %reg1024 = load <fi#-1> %reg1025 = load <fi#-2> setcc %reg1024, %reg1025 goto %disp(label then) goto %disp(label else) then (0x8681688): %reg1026 = + %reg1025, %reg1024 %gr7 = move %reg1026 return else (0x86815e0): %reg1027 = + %reg1025, %reg1024 %gr7 = move %reg1028 return # End machine code for _Z3addii(). Code after register allocation # Machine code for _Z3addii(): <fi #-2> is 4 bytes fixed at location [SP-20] <fi #-...

On Wed, 9 Jun 2004, Vladimir Prus wrote: > Chris Lattner wrote: > > > Thanks, this works! I don't yet understand why spill code is needed there > > > at all, but I'll return to that when I have branches working correctly. > > > > I'm not sure either. Can you send the code before and after register > > allocation? > > Attached. Okay, yeah

...VALS ********** ********** Function: _Z3addii entry: 0 %reg1024 = load <fi#-1> register: %reg1024 +[20,22) +[32,34) +[2,20) 4 %reg1025 = load <fi#-2> register: %reg1025 +[20,22) +[32,34) +[6,20) 8 setcc %reg1024, %reg1025 12 goto %disp(label then) 16 goto %disp(label else) then: 20 %reg1026 = + %reg1025, %reg1024 register: %reg1026 +[22,26) 24 %gr7 = move %reg1026 register: gr7 dead +[26,27) 28 return else: 32 %reg1027 = + %reg1025, %reg1024 register: %reg1027 +[34,35) 36 %gr7 = move %reg1028 register: gr7 dead +[38,39) 40 return ********** JOINING INTERVALS *********** entry:...

...gt; 0x391c8b0: v2f64 = scalar_to_vector 0x391ac10 srcLineNum= 10 0x3927b10: <multiple use> 0x3923100: v2f64 = vector_shuffle 0x391c970, 0x391c8b0, 0x3927b10<0,2> srcLineNum= 10 The code that gets produced looks like this: %reg1071<def> = MOVSD2PDrm %reg1026, 8, %reg1065, 4294967288, Mem:LD(8,8) [r66428 + 0]LD(8,8) [r78427 + 0] ; srcLine 10 %reg1072<def> = MOVSD2PDrm %reg1026, 8, %reg1065, 4294967288, Mem:LD(8,8) [r66428 + 0]LD(8,8) [r78427 + 0] ; srcLine 10 %reg1073<def> = SHUFPDrri %reg1071, %reg1072, 0 ; srcLine 10 Note that %reg...

...I'll see if I can generate a .ll testcase. The llvm tools probably won't fail because they don't contain the assert that I have in my code. Here are the steps of what happens in MergeInClobberRanges: 1. IP = [0,10:0 [0]) (begin() for %reg15) 2. I = [458,5168:0 [0]) (begin() for %reg1026) 3. Start = 458, End = 5168 4. IP = [938,942:1 [0]) (std::upper_bound(IP, end(), Start) 5. IP != begin() && IP[-1].end > Start is FALSE 6. IP != end() && End > IP->start is TRUE 7. End = 938 (IP->start) 8. Start == End is FALSE 9. IP = [458,938:89 [0]) (addRa...

...to be a conservative update for the > purposes of coalescing? > > > In any event, it seems not to be working right if what you > describe is supposed to be happening. > > Given the two intervals in my example, which should happen > with the two overlappring ranges > > %reg1026: [458,5168:0 [0]) > %reg15: [938,942:1 [0]) > > My assumption was that after MergeInClobberRanges that %reg15 > would contain [458,5168:0 [0]). But it doesn't. So this is the call site? // Update the liveintervals of sub-registers. for (const unsigned *AS = tri_->ge...

...0 srcLineNum= 10 >> 0x3927b10: <multiple use> >> 0x3923100: v2f64 = vector_shuffle 0x391c970, 0x391c8b0, >> 0x3927b10<0,2> srcLineNum= 10 >> >> The code that gets produced looks like this: >> >> %reg1071<def> = MOVSD2PDrm %reg1026, 8, %reg1065, 4294967288, >> Mem:LD(8,8) >> [r66428 + 0]LD(8,8) [r78427 + 0] ; srcLine 10 >> %reg1072<def> = MOVSD2PDrm %reg1026, 8, %reg1065, 4294967288, >> Mem:LD(8,8) >> [r66428 + 0]LD(8,8) [r78427 + 0] ; srcLine 10 >> %reg1073<def> = SHUFP...

On Thursday 21 February 2008 10:53, David Greene wrote: > Why do we do this trimming? The comment seems to say we don't care about > the rest of the live range from Clobbers (%reg1026 in this case) but that > doesn't match with our expectation that %reg15 will contain all of the live > range information from %reg1026. I'll add that merging this correctly could get tricky. %reg15 contains the following live ranges, all of which overlap [458,5168:0 [0]) from %reg1...

I'm debugging some X86 patterns and I want to understand the debug dumps from isel better. Here's some example output: 0x391bc40: i64,ch = load 0x3922c50, 0x391b8d0, 0x38dc530 <0x39053e0:0> <sext i32> alignment=4 srcLineNum= 10 0x3922c50: <multiple use> 0x391bc40: <multiple use> 0x3856ab0: <multiple use> 0x3914520: i64 =

On Wed, 21 Oct 2009, Lang Hames wrote: > There are any number of things that can go wrong in register allocation, so > it's hard for me to guess without seeing your code. > > Possible issues: > > 2) How are you making sure that interfering virtregs never receive the same > physreg? If you're using the LiveIntervals analysis (and the >

...- NOP Each pairs could be issued in parallel. However, "one single MachineInstr" is the "unit" of many passes, e.g. LiveVariables and LiveIntervals. Without modifications, some code-gen result may be inefficient (or incorrect). For example: mul %reg1025, %reg1024, 1 add %reg1026, %reg1024, 2 Suppose the life interval of %reg1024 ends at ADD (no use after ADD). These two instructions are not dependent and could be scheduled together: mul %reg1024, %reg1025, 1 - add %reg1026, %reg1025, 2 The life intervals of vi%reg1024 and %reg1025 are actually _not_ interfered with...

...ed like this: # Machine code for list_sequence(): <fi #-2> is 4 bytes fixed at location [SP-24] <fi #-1> is 4 bytes fixed at location [SP-20] entry (0x8060970, LLVM BB @0x805da88): %reg1024 = load <fi#-1> %reg1025 = load <fi#-2> setcc %reg1025, %reg1026 (so 'reg1026' is used before definition). It would be nice if register allocator responded with a nice 'register used before definition in instruction ....' message. What I get now is: Program received signal SIGSEGV, Segmentation fault. 0x400c24d4 in llvm::MachineInstr::getPare...

...of as registers, but > they have the same property. They are accessed with in/out instructions, > not with "register writes". If the output register is represented by an immediate operand or belongs to a different register class, the following sequence: add %reg1024, %reg1025, %reg1026 out %o1, %reg1024 // out is an intrinsic, there is no such machine instruction // o1 is a write-only output register, mapping to a physical output port cannot be changed to: add %o1, %reg1025, %reg1026 because LiveIntervals::joinIntervalsInMachineBB() requires one of the operands of a ...

...#39; failed. when attempting to allocate this machine function: entry: 4 %reg1024<def,dead> = MOV32rr %EDI<kill> 12 %reg1025<def,dead> = MOV64rr %RSI<kill> 20 ADJCALLSTACKDOWN 0, %ESP<imp-def>, %EFLAGS<imp-def,dead>, %ESP<imp-use> 28 %reg1026<def> = MOV8ri 4 36 %reg1027<def> = FsFLD0SD 44 %reg1028<def> = LEA64r %reg0, 1, %reg0, <ga:.str1> 52 %RDI<def> = MOV64rr %reg1028<kill> 60 %XMM0<def> = FsMOVAPDrr %reg1027 68 %XMM1<def> = FsMOVAPDrr %reg1027 76 %XMM2<d...

...********** REWRITING TWO-ADDR INSTRS ********** ********** Function: sext %reg1028<def> = sextb_r %reg1025<kill> prepend: %reg1028<def> = mov_rr %reg1025<kill> rewrite to: %reg1028<def> = sextb_r %reg1028 ... %reg1030<def> = sextw_r %reg1026<kill> prepend: %reg1030<def> = mov_rr %reg1026<kill> rewrite to: %reg1030<def> = sextw_r %reg1030 Because sextb_r and sextw_r have destination tied to source operands, TwoAddressInstructionPass thinks it needs a copy. However, since the sext kills its...

Hi Susan, > 1. I tried running the PBQP allocator (as a dynamic pass), but that didn't > work.... Can you tell from this what I'm doing wrong? > The PBQP allocator is built into the LLVM CodeGen library, so the "-regalloc=pbqp" option is already available in llc. If you've built a copy of the PBQP allocator in a separate library it will try to re-register

...ocate this machine function: > > entry: > 4 %reg1024<def,dead> = MOV32rr %EDI<kill> > 12 %reg1025<def,dead> = MOV64rr %RSI<kill> > 20 ADJCALLSTACKDOWN 0, %ESP<imp-def>, %EFLAGS<imp-def,dead>, > %ESP<imp-use> > 28 %reg1026<def> = MOV8ri 4 > 36 %reg1027<def> = FsFLD0SD > 44 %reg1028<def> = LEA64r %reg0, 1, %reg0, <ga:.str1> > 52 %RDI<def> = MOV64rr %reg1028<kill> > 60 %XMM0<def> = FsMOVAPDrr %reg1027 > 68 %XMM1<def> = FsMOVAPDrr %r...

On Feb 21, 2008, at 9:06 AM, David Greene wrote: > On Thursday 21 February 2008 10:53, David Greene wrote: > >> Why do we do this trimming? The comment seems to say we don't care >> about >> the rest of the live range from Clobbers (%reg1026 in this case) >> but that >> doesn't match with our expectation that %reg15 will contain all of >> the live >> range information from %reg1026. > > I'll add that merging this correctly could get tricky. %reg15 > contains the > following live ranges...

On Sep 1, 2010, at 11:14 AM, Dale Johannesen wrote: > > On Sep 1, 2010, at 6:25 AMPDT, Argyrios Kyrtzidis wrote: > >> The attached .ll files seem equivalent, but the resulting asm from >> 'opt-fail.ll' causes a crash to webkit. >> I suspect the usage of registers is wrong, can someone take a look ? > > Yes, the code here is wrong: > >> movl