[llvm] r316481 - bpf: fix a bug in trunc-op optimization

Yonghong Song via llvm-commits llvm-commits at lists.llvm.org
Tue Oct 24 14:52:31 PDT 2017


Thanks. The issue is fixed.

On 10/24/17 2:32 PM, Evgenii Stepanov wrote:
> Nope, for PODs default initialiization does nothing:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__en.cppreference.com_w_cpp_language_default-5Finitialization&d=DwIFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=DA8e1B5r073vIqRrFz7MRA&m=_iK4IPAR_bca_2oCbDujor3RDMz4X25xfKjwT7R2K1s&s=hJSTJaAKofoLe4MoTo6nD27Y2mkYX0YUJzd8pYwd7tY&e=
> 
> 
> On Tue, Oct 24, 2017 at 2:22 PM, Yonghong Song <yhs at fb.com> wrote:
>>
>> Yes. Previously, I do have this change. Later on, I checked some
>> website (stackflow) which says, the constructor will assign NULL
>> to a pointer value so that is why I did not initialize it in
>> the constructor.
>> Maybe my understanding is incorrect?
>>
>> On 10/24/17 2:19 PM, Evgenii Stepanov wrote:
>>>
>>> All stores to curr_func_ are dominated by loads, this can't be right.
>>> You probably meant to initialize it to nullptr in the constructor?
>>>
>>> On Tue, Oct 24, 2017 at 2:17 PM, Evgenii Stepanov
>>> <eugeni.stepanov at gmail.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> one of your changes broke the msan bot:
>>>>
>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lab.llvm.org-3A8011_builders_sanitizer-2Dx86-5F64-2Dlinux-2Dbootstrap-2Dmsan_builds_202_steps_check-2Dllvm-2520msan_logs_stdio&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=DA8e1B5r073vIqRrFz7MRA&m=IkIAE-IfCDp2GWYOR5YHSXgGYE1V30dpyuL_J7-UFWg&s=huyyhqno9qhlXkirQWhS6bHMR6lgp_oWD_K7SZtkVQ4&e=
>>>>
>>>> On Tue, Oct 24, 2017 at 11:21 AM, Yonghong Song via llvm-commits
>>>> <llvm-commits at lists.llvm.org> wrote:
>>>>>
>>>>> Author: yhs
>>>>> Date: Tue Oct 24 11:21:10 2017
>>>>> New Revision: 316481
>>>>>
>>>>> URL:
>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D316481-26view-3Drev&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=DA8e1B5r073vIqRrFz7MRA&m=IkIAE-IfCDp2GWYOR5YHSXgGYE1V30dpyuL_J7-UFWg&s=taKxbRkvdYyRFORIGxTNt44Z5yDJeNtIwPYGuGot5zk&e=
>>>>> Log:
>>>>> bpf: fix a bug in trunc-op optimization
>>>>>
>>>>> Previous implementation for per-function scope
>>>>> is incorrect and too conservative.
>>>>>
>>>>> Signed-off-by: Yonghong Song <yhs at fb.com>
>>>>>
>>>>> Modified:
>>>>>       llvm/trunk/lib/Target/BPF/BPFISelDAGToDAG.cpp
>>>>>
>>>>> Modified: llvm/trunk/lib/Target/BPF/BPFISelDAGToDAG.cpp
>>>>> URL:
>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_llvm_trunk_lib_Target_BPF_BPFISelDAGToDAG.cpp-3Frev-3D316481-26r1-3D316480-26r2-3D316481-26view-3Ddiff&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=DA8e1B5r073vIqRrFz7MRA&m=IkIAE-IfCDp2GWYOR5YHSXgGYE1V30dpyuL_J7-UFWg&s=9ml3oJPI84s7znc7K8tKbmG-kvwiOIJknrq06ZknAzU&e=
>>>>>
>>>>>
>>>>> ==============================================================================
>>>>> --- llvm/trunk/lib/Target/BPF/BPFISelDAGToDAG.cpp (original)
>>>>> +++ llvm/trunk/lib/Target/BPF/BPFISelDAGToDAG.cpp Tue Oct 24 11:21:10
>>>>> 2017
>>>>> @@ -85,6 +85,8 @@ private:
>>>>>      std::map<const void *, val_vec_type> cs_vals_;
>>>>>      // Mapping from vreg to load memory opcode
>>>>>      std::map<unsigned, unsigned> load_to_vreg_;
>>>>> +  // Current function
>>>>> +  const Function *curr_func_;
>>>>>    };
>>>>>    } // namespace
>>>>>
>>>>> @@ -332,7 +334,12 @@ void BPFDAGToDAGISel::PreprocessISelDAG(
>>>>>
>>>>>      // clear the load_to_vreg_ map so that we have a clean start
>>>>>      // for this function.
>>>>> -  load_to_vreg_.clear();
>>>>> +  if (!curr_func_) {
>>>>> +    curr_func_ = FuncInfo->Fn;
>>>>> +  } else if (curr_func_ != FuncInfo->Fn) {
>>>>> +    load_to_vreg_.clear();
>>>>> +    curr_func_ = FuncInfo->Fn;
>>>>> +  }
>>>>>
>>>>>      for (SelectionDAG::allnodes_iterator I = CurDAG->allnodes_begin(),
>>>>>                                           E = CurDAG->allnodes_end();
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> llvm-commits mailing list
>>>>> llvm-commits at lists.llvm.org
>>>>>
>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Dcommits&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=DA8e1B5r073vIqRrFz7MRA&m=IkIAE-IfCDp2GWYOR5YHSXgGYE1V30dpyuL_J7-UFWg&s=ne_gxt12LtqOdekNE55Pyhfyj8Wst9bRmyUC-plnG3w&e=


More information about the llvm-commits mailing list