Displaying 4 results from an estimated 4 matches for "i1_l".
2009 Mar 15
5
[LLVMdev] Overlapping register classes
...[(set GR:$dst, imm:$src)]>;
I think I am stretching 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
Sch...
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
...]>;
>
> I think I am stretching 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 a...
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. RALi...