search for: reg1024

...amp;): Assertion `r2iit != r2iMap_.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 ma...

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

...lodya -------------- next part -------------- Instruction: %tmp.9 = shl int %tmp.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...

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

...BuildMI(BB, NM::GOTO, 1).addPCDisp(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...

...Tue, 8 Jun 2004, 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 o...

...ld I model these sub-registers. 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. He...

...ese are not 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...

Evan, thanks for responding so quickly. On Tuesday 26 June 2007 14:11, Evan Cheng wrote: > On Jun 26, 2007, at 11:20 AM, David A. Greene wrote: > > 28 %AL<dead> = MOV8rr %reg1024<kill>, %EAX<imp-def> > > MOV8rr %mreg(2)<d> %reg1024 %mreg(17)<d> > > 32 CALL64pcrel32 <ga:printf>, %RDI<kill>, %RAX<imp-def>, %RCX<imp- > > def,dead>, > > %RDX<imp-def,dead>, %RSI<imp-def,dead>, %RDI<imp-def,dea...

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

On Tuesday 26 June 2007 14:57, David Greene wrote: > > EAX and its sub-registers are defined by the MOV8rr instruction > > > > implicitly: > > > 28 %AL<dead> = MOV8rr %reg1024<kill>, %EAX<imp-def> > > > MOV8rr %mreg(2)<d> %reg1024 %mreg(17)<d> > > > > So their live ranges start at 28+2. > > Yep, this makes sense to me. But AL is a subregister of RAX too, > so shouldn't it have a live interval that starts there as...

On Tue, 8 Jun 2004, 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,...

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

...FNSTCW16m <fi#0> 1 %mreg(0) 0 4 MOV8mi <fi#0>, 1, %NOREG, 1, 2 MOV8mi <fi#0> 1 %mreg(0) 1 2 8 FLDCW16m <fi#0>, 1, %NOREG, 0 FLDCW16m <fi#0> 1 %mreg(0) 0 12 ADJCALLSTACKDOWN 0, %ESP<imp-def>, %ESP<imp-use> ADJCALLSTACKDOWN 0 %mreg(25)<d> %mreg(25) 16 %reg1024 = MOV8r0 MOV8r0 %reg1024<d> 20 %reg1025 = LEA64r %NOREG, 1, %NOREG, <ga:initialized$$$CFE_id_cc092431_main> LEA64r %reg1025<d> %mreg(0) 1 %mreg(0) <ga:initialized$$$CFE_id_cc092431_main> 24 %RDI = MOV64rr %reg1025<kill> MOV64rr %mreg(78)<d> %reg1025 28 %AL<de...

...t;stdio.h> | entry (0x8d4c6c0, LLVM BB @0x8d46970): | FNSTCW16m <fi#0>, 1, %NOREG, 0 int main() { | MOV8mi <fi#0>, 1, %NOREG, 1, 2 return 0; | FLDCW16m <fi#0>, 1, %NOREG, 0 } | %reg1024 = MOV32r0 | %EAX = MOV32rr %reg1024 | RET llc((anonymous namespace)::PrintStackTrace()+0x18)[0x88cfa30] llc((anonymous namespace)::SignalHandler(int)+0x107)[0x88cfcc1] /lib/tls/libc.so.6[0x239f48] llc(llvm::MachineFunctionPass::runOnFunctio...

...the scalars operations back into 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...

...; implicit use of V4R0 at first ORI but 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...

On Jun 26, 2007, at 11:20 AM, David A. Greene wrote: > > 28 %AL<dead> = MOV8rr %reg1024<kill>, %EAX<imp-def> > MOV8rr %mreg(2)<d> %reg1024 %mreg(17)<d> > 32 CALL64pcrel32 <ga:printf>, %RDI<kill>, %RAX<imp-def>, %RCX<imp- > def,dead>, > %RDX<imp-def,dead>, %RSI<imp-def,dead>, %RDI<imp-def,dead>, > %R8<...

...| entry (0x8d4c6c0, LLVM BB @0x8d46970): > | FNSTCW16m <fi#0>, 1, %NOREG, 0 > int main() { | MOV8mi <fi#0>, 1, %NOREG, 1, 2 > return 0; | FLDCW16m <fi#0>, 1, %NOREG, 0 > } | %reg1024 = MOV32r0 > | %EAX = MOV32rr %reg1024 > | RET > > llc((anonymous namespace)::PrintStackTrace()+0x18)[0x88cfa30] > llc((anonymous namespace)::SignalHandler(int)+0x107)[0x88cfcc1] > /lib/tls/libc.so.6[0x239f48] > llc(llvm::M...

..., reg); > > LiveInterval &RegInt = getInterval(reg); > RegInt.weight += > (mop.isUse() + mop.isDef()) * pow(10.0F, (int)loopDepth); > After joining intervals some moves are unecessary. If for example this instruction was in the code: mov %reg1024, %reg1045 and intervals for reg1024 and reg1045 were joined, only one register needs to be present in the pre register-allocation machine code. So all references to reg1024 and reg1045 are replaced with a reference to their representative register (found using a union find algorithm). Note that th...