[llvm-dev] Backend subtraction changed to negative addition

Philip Herron via llvm-dev llvm-dev at lists.llvm.org
Wed Jan 25 16:43:37 PST 2017


This looks to be exactly what i need. Though this instruction set i am
working with does not support immedites. It has a load constant to register
instruction is the only way to load immedites. So i am not sure if this
pattern will pick that up correctly. Will give it a test.

Thanks

--Phil

On 25 January 2017 at 21:23, Matt Arsenault <Matthew.Arsenault at amd.com>
wrote:

> On 01/25/2017 01:05 PM, Philip Herron via llvm-dev wrote:
>
>> Hi all,
>>
>> I am writing a custom backend. Doing more testing i notice that for some
>> reason something like:
>>
>> int test(int x) { return x - 1; }
>>
>> is being turned into this IR:
>>
>> ; Function Attrs: nounwind
>> define i32 @test(i32 %n) #0 {
>> entry:
>>   %n.addr = alloca i32, align 4
>>   store i32 %n, i32* %n.addr, align 4
>>   %0 = load i32* %n.addr, align 4
>>   %sub = sub nsw i32 %0, 1
>>   ret i32 %sub
>> }
>>
>> But finally in code generation i am getting:
>>
>> ldc r2, #-1
>> add r0, r2, r0
>>
>> Should this not be doing:
>>
>> ldc r2 #1
>> sub r0 r2 r0
>>
>> I have defined both my add and sub instructions:
>>
>> def ADD : ALUInst<0b0001, (outs GRRegs:$dst),
>>                    (ins GRRegs:$src1, GRRegs:$src2),
>>                    "add $src1, $src2, $dst",
>>                    [(set i32:$dst, (add i32:$src1, i32:$src2))]>;
>>
>> def SUB : ALUInst<0b0010, (outs GRRegs:$dst),
>>                    (ins GRRegs:$src1, GRRegs:$src2),
>>                    "sub $src1, $src2, $dst",
>>                    [(set i32:$dst, (sub i32:$src1, i32:$src2))]>;
>>
>> Is there a way to override this behaviour?
>>
>
> You can add an optimization pattern for this. I have a patch to do this
> for AMDGPU since it costs code size in some cases as an example:
> https://reviews.llvm.org/D28043
>
> -Matt
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170126/82569894/attachment.html>


More information about the llvm-dev mailing list