search for: reg1025

...Map_.end()' failed. - Volodya -------------- next part -------------- Code after instruction selection # Machine code for _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(). Cod...

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

...mp.8, ubyte 1 ; <int> [#uses=1] Machine Function ********** REWRITING TWO-ADDR INSTRS ********** ********** Function: _Z3addii ********** COMPUTING LIVE INTERVALS ********** ********** 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...

...MUL - ADD ADD - NOP MUL - 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 act...

...PCDisp(BI.getSuccessor(0)); BuildMI(BB, NM::GOTO, 1).addPCDisp(BI.getSuccessor(1)); } The machine code after instruction selection is: 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 .... which looks ok, but after register allocation and prolog/epilog...

...While adding support for branch instructions in my backend, I run into a > > trouble. The code to handle branches looks like: > > The machine code after instruction selection is: > > > > entry (0x8681458): > > %reg1024 = load <fi#-1> > > %reg1025 = load <fi#-2> > > setcc %reg1024, %reg1025 > > goto %disp(label then) > > goto %disp(label else) > > I assume that the two unconditional gotos are just test code, right? If > not, the second one is dead. Yes, in the final form there will b...

...gt;> %retval = select i1 false, i32 %a, i32 %b ; >> <i32> [#uses=0] >> ret void >> } >> >> I get this error: >> >> entry (0x8503b90, LLVM BB @0x8501b00, ID#0): >> %reg1024 = ORI %R0, 0 >> %reg1025 = ORI %R1, 0 >> RETL >> Machine Function >> ********** REWRITING TWO-ADDR INSTRS ********** >> ********** Function: _Z3fooff >> >> ********** COMPUTING LIVE INTERVALS ********** >> ********** Function: _Z3fooii >> entry: >>...

...4, Vladimir Prus wrote: > While adding support for branch instructions in my backend, I run into a > trouble. The code to handle branches looks like: > The machine code after instruction selection is: > > entry (0x8681458): > %reg1024 = load <fi#-1> > %reg1025 = load <fi#-2> > setcc %reg1024, %reg1025 > goto %disp(label then) > goto %disp(label else) I assume that the two unconditional gotos are just test code, right? If not, the second one is dead. > which looks ok, but after register allocation and prolog/ep...

On Wed, 9 Jun 2004, Vladimir Prus wrote: > > I assume that the two unconditional gotos are just test code, right? If > > not, the second one is dead. > > Yes, in the final form there will be "iflt" instruction before the first goto, > making it conditional. Ah, ok :) > > > The code after "goto" is disturbing. It looks like spill code, but

...to it" issue. Due to a bug, my machine code looked 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, Segment...

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

...t thought 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 operan...

...it should not be marked kill. >> If it is marked kill, then you need to walk LiveVariables.cpp to >> find out why. > > Here is the beginning of the BB dump. > > entry (0x8503c80, LLVM BB @0x8501af0, ID#0): > Live Ins: %R0 %R1 > %reg1024 = ORI %R0<kill>, 0 > %reg1025 = ORI %R1<kill>, 0 > > V4R0 is getting killed because handleLiveInRegister() is called on > all results of getAliasSet() for each of the liveins (this is in > LiveIntervals::computeIntervals() ). > > handleRegisterDef() does a similar thing where calls > handlePhysicalReg...

...### unnecessary move add r1,r4 jmp [r30] Which should be this: sext: sextb r1 add r1,r3 sextw r2 add r1,r2 jmp [r30] The debug output from LLVM shows this: ********** 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: %re...

...s. If I treat each component as a register, and do the register allocation individually, it seems very difficult to merge the scalars operations back into one vetor operation. // each %reg is a sub-register // r1, r2, r3, r4 here are virtual register number mul %reg1024, r1, r2 // x mul %reg1025, r1, r2 // y mul %reg1026, r1, r2 // z add %reg1027, r3, r4 // w sub %reg1028, %reg1024, r1 sub %reg1029, %reg1025, r1 sub %reg1030, %reg1026, r1 sub %reg1031, %reg1027, r1 So I decided to model each 4-element register as one Register in *.td file. Here are the details. Since al...

...re dead code is making it down to the codegen level? > > -Chris > I think so. LLVM is producing code like this one here, before RA: ---------------------------------------------------------------------------- entry (0x8605ba0, LLVM BB @0x8602d30): %reg1024 = OR4 %r3, %r3 %reg1025 = OR4 %r4, %r4 %reg1026 = LWZ 0, %reg1025 %reg1027 = LIS <ga:.str_1> %reg1028 = LIS <ga:.str_2> %reg1029 = LBZ 0, %reg1026 ADJCALLSTACKDOWN 56 %reg1030 = IMPLICIT_DEF_GPR %reg1031 = LA %reg1027, <ga:.str_1> %r3 = OR4...

...CFG: 0x839d130 (#3) 0x8462780 (#35) 308 %reg1051 = MOV64rr %reg1227<kill> 312 %reg1052 = MOV64rr %reg1228<kill> 316 %reg1053 = MOV64rr %reg1229<kill> 320 %reg1054 = MOV64rr %reg1230<kill> 324 %reg1055<dead> = LEA64r %reg1047, 1, %reg1053, 0 328 %reg1135 = MOVSX64rr32 %reg1025 332 %reg1136 = MOV64rr %reg1135<kill> 336 %reg1136 = ADD64ri32 %reg1136, -4, %EFLAGS<imp-def,dead> 340 TEST64rr %reg1136<kill>, %reg1136, %EFLAGS<imp-def> 344 JNS mbb<file solve.f, line 23, in loop at depth 1, bb16,0x83a2c70>, %EFLAGS<imp-use,kill> Here we have...

...llc: VirtRegMap.cpp:1733: void<unnamed>::LocalSpiller::RewriteMBB(llvm::MachineBasicBlock&, llvm::VirtRegMap&): Assertion `KillRegs[0] == Dst' 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 %...

...lt;1>; when trying to compile: define void @_Z3fooii(i32 %a, i32 %b) { entry: %retval = select i1 false, i32 %a, i32 %b ; <i32> [#uses=0] ret void } I get this error: entry (0x8503b90, LLVM BB @0x8501b00, ID#0): %reg1024 = ORI %R0, 0 %reg1025 = ORI %R1, 0 RETL Machine Function ********** REWRITING TWO-ADDR INSTRS ********** ********** Function: _Z3fooff ********** COMPUTING LIVE INTERVALS ********** ********** Function: _Z3fooii entry: livein register: R0 killed +[0,2:0) livein register: V4R0...

...one vetor > operation. Well, how many possible permutations are there? Is it possible to model each case as a separate physical register? Evan > // each %reg is a sub-register > // r1, r2, r3, r4 here are virtual register number > > mul %reg1024, r1, r2 // x > mul %reg1025, r1, r2 // y > mul %reg1026, r1, r2 // z > > add %reg1027, r3, r4 // w > > sub %reg1028, %reg1024, r1 > sub %reg1029, %reg1025, r1 > sub %reg1030, %reg1026, r1 > sub %reg1031, %reg1027, r1 > > So I decided to model each 4-element register as one Register...