[llvm] 3cb7e7b - BPF: fix a CORE optimization bug

Yonghong Song via llvm-commits llvm-commits at lists.llvm.org
Mon Apr 20 20:08:13 PDT 2020



On 4/20/20 8:05 PM, Tom Stellard wrote:
> On 04/20/2020 08:04 PM, Yonghong Song via llvm-commits wrote:
>>
>> Author: Yonghong Song
>> Date: 2020-04-20T19:54:51-07:00
>> New Revision: 3cb7e7bf959dcd3b8080986c62e10a75c7af43f0
>>
> 
> Should we backport this to the release/10.x branch?

Yes. This is my plan. I did not find any information about 10.0.1
release ticket number. Do you have a tracking ticket number I can use
to track this backport?

> 
> -Tom
> 
>> URL: https://github.com/llvm/llvm-project/commit/3cb7e7bf959dcd3b8080986c62e10a75c7af43f0
>> DIFF: https://github.com/llvm/llvm-project/commit/3cb7e7bf959dcd3b8080986c62e10a75c7af43f0.diff
>>
>> LOG: BPF: fix a CORE optimization bug
>>
>> For the test case in this patch like below
>>    struct t { int a; } __attribute__((preserve_access_index));
>>    int foo(void *);
>>    int test(struct t *arg) {
>>        long param[1];
>>        param[0] = (long)&arg->a;
>>        return foo(param);
>>    }
>>
>> The IR right before BPF SimplifyPatchable phase:
>>    %1:gpr = LD_imm64 @"llvm.t:0:0$0:0"
>>    %2:gpr = LDD killed %1:gpr, 0
>>    %3:gpr = ADD_rr %0:gpr(tied-def 0), killed %2:gpr
>>    STD killed %3:gpr, %stack.0.param, 0
>> After SimplifyPatchable phase, the incorrect IR is generated:
>>    %1:gpr = LD_imm64 @"llvm.t:0:0$0:0"
>>    %3:gpr = ADD_rr %0:gpr(tied-def 0), killed %1:gpr
>>    CORE_MEM killed %3:gpr, 306, %0:gpr, @"llvm.t:0:0$0:0"
>>
>> Note that CORE_MEM pseudo op is introduced to encode
>> memory operations related to CORE. In the above, we intend
>> to check whether we have a store like
>>     *(%3:gpr + 0) = ...
>> and if this is the case, we could replace it with
>>     *(%0:gpr + @"llvm.t:0:0$0:0"_ = ...
>>
>> Unfortunately, in the above, IR for the store is
>>     *(%stack.0.param + 0) = %3:gpr
>> and transformation should not happen.
>>
>> Note that we won't have problem if the actual CORE
>> dereference (arg->a) happens.
>>
>> This patch fixed the problem by skip CORE optimization if
>> the use of ADD_rr result is not the base address of the store
>> operation.
>>
>> Differential Revision: https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D78466&d=DwICaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=DA8e1B5r073vIqRrFz7MRA&m=M4_uRgblk7fIvBK0OPXqlguO1L7b3oP5ZH_bYDGtD4k&s=SD4faapHI4Z__Jhwpfz7s4ro7MFn1w7vfMCvalkow_k&e=
>>
>> Added:
>>      llvm/test/CodeGen/BPF/CORE/store-addr.ll
>>
>> Modified:
>>      llvm/lib/Target/BPF/BPFMISimplifyPatchable.cpp
>>
>> Removed:
>>      
>>
>>
>> ################################################################################
>> diff  --git a/llvm/lib/Target/BPF/BPFMISimplifyPatchable.cpp b/llvm/lib/Target/BPF/BPFMISimplifyPatchable.cpp
>> index 29abc9303a62..b2ecb531db9d 100644
>> --- a/llvm/lib/Target/BPF/BPFMISimplifyPatchable.cpp
>> +++ b/llvm/lib/Target/BPF/BPFMISimplifyPatchable.cpp
>> @@ -116,11 +116,22 @@ void BPFMISimplifyPatchable::checkADDrr(MachineRegisterInfo *MRI,
[...]


More information about the llvm-commits mailing list