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

[Tom Stellard via llvm-commits]

On 04/20/2020 08:08 PM, Yonghong Song wrote:
> 
> 
> 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?
> 

This is the tracking bug:

https://bugs.llvm.org/show_bug.cgi?id=release-10.0.1

-Tom

>>
>> -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,
> [...]
>