search for: i1_ls

Displaying 4 results from an estimated 4 matches for "i1_ls".

Did you mean: i1_l
2009 Mar 15
5
[LLVMdev] Overlapping register classes
...g the code generator beyond its capability by doing this. As far as I can tell, instruction selection is done purely based on value types. Register classes are not considered. I get in trouble when I try to compile this function: @i1_l = external global i1 @i1_s = external global i1 define void @i1_ls() nounwind { %tmp = load i1* @i1_l store i1 %tmp, i1* @i1_s ret void } Instruction selection works correctly, but the scheduling step fails with "Register class of operand and regclass of use don't agree!" in ScheduleDAGSDNodes::AddOperand. The selected DAG contains: (LOAD32...
2009 Mar 16
2
[LLVMdev] Overlapping register classes
...subregs > are emitted with a copy (MOV32to32_) to put the value in a virtual > register of the needed class. This copy may then optimized away > by subsequent passes. I missed this before (thanks, Eli). I tried adding the explicit move patterns, and at least it compiles correctly now: i1_ls: R0.H = HI(i1_l); R0.L = LO(i1_l); P0 = R0; R0.H = HI(i1_s); R0.L = LO(i1_s); R1 = B[P0] (Z); R2 = 1 (X); P0 = R0; R0 = R1 & R2; B[P0] = R0; RTS; The moves (P0 = R0) did not get optimized away by the register allocator. RALinScan::attemptTrivialCoalescing almost succeeded; it got as...
2009 Mar 16
0
[LLVMdev] Overlapping register classes
...by > doing this. As far as I can tell, instruction selection is done purely > based on value types. Register classes are not considered. > > I get in trouble when I try to compile this function: > > @i1_l = external global i1 > @i1_s = external global i1 > > define void @i1_ls() nounwind { > %tmp = load i1* @i1_l > store i1 %tmp, i1* @i1_s > ret void > } > > Instruction selection works correctly, but the scheduling step fails > with "Register class of operand and regclass of use don't agree!" in > ScheduleDAGSDNodes::AddOperand....
2009 Mar 17
0
[LLVMdev] Overlapping register classes
...a copy (MOV32to32_) to put the value in a virtual >> register of the needed class. This copy may then optimized away >> by subsequent passes. > > I missed this before (thanks, Eli). I tried adding the explicit move > patterns, and at least it compiles correctly now: > > i1_ls: > R0.H = HI(i1_l); R0.L = LO(i1_l); > P0 = R0; > R0.H = HI(i1_s); R0.L = LO(i1_s); > R1 = B[P0] (Z); > R2 = 1 (X); > P0 = R0; > R0 = R1 & R2; > B[P0] = R0; > RTS; > > The moves (P0 = R0) did not get optimized away by the register > allocator. RALin...