[PATCH] D20262: [DSE]Split memset when the memset is small enough to be lowered to stores

Mehdi Amini via llvm-commits llvm-commits at lists.llvm.org
Wed Jun 1 14:57:01 PDT 2016


> On Jun 1, 2016, at 11:02 AM, Jun Bum Lim <junbuml at codeaurora.org> wrote:
> 
> Hi Mehdi,
> 
> Do you expect  DL.getLargestLegalIntTypeSizeInBits() always return non-zero?

So I checked the code (and doxygen) and indeed it is expected to be an optional information on the DataLayout.
The default data-layout won't specify it, and clients should handle the zero case.


-- 
Mehdi


> However, using the test case added in this patch, we can easily make
> DL.getLargestLegalIntTypeSizeInBits() return  0 whenever we remove
> datalayout in the IR below.  Please correct me if I miss something here. 
> 
> ;  RUN: opt < %s -basicaa -dse -mtriple=arm64-linux-gnu -S 
> 
> ; target datalayout = "e-m:e-i64:64-i128:128-n32:64-S128"
> 
> define void @test_32_8to15(i64* nocapture %P, i64 %n64) #0 {
> entry:
> %0 = bitcast i64* %P to i8*
> call void @llvm.memset.p0i8.i64(i8* %0, i8 0, i64 32, i32 8, i1 false)
> %arrayidx1 = getelementptr inbounds i64, i64* %P, i64  1  store i64 %n64,
> i64* %arrayidx1  ret void }
> 
> 
> Thanks,
> Jun
> 
> 
> -----Original Message-----
> From: mehdi.amini at apple.com [mailto:mehdi.amini at apple.com] 
> Sent: Wednesday, June 01, 2016 1:26 PM
> To: reviews+D20262+public+d72d68e64d18c977 at reviews.llvm.org
> Cc: junbuml at codeaurora.org; hfinkel at anl.gov; eeckstein at apple.com;
> mcrosier at codeaurora.org; dberlin at dberlin.org; qcolombet at apple.com;
> llvm-commits at lists.llvm.org
> Subject: Re: [PATCH] D20262: [DSE]Split memset when the memset is small
> enough to be lowered to stores
> 
> 
>> On Jun 1, 2016, at 8:47 AM, Jun Bum Lim <junbuml at codeaurora.org> wrote:
>> 
>> junbuml added a comment.
>> 
>>> http://llvm.org/docs/doxygen/html/Module_8cpp_source.html#l00375
>> 
>>> "const DataLayout &Module::getDataLayout() const { return DL; }"
>> 
>>> It returns a reference, so it is guaranteed to not be null.
>> 
>>> "No data layout in the Textual IR means "use the default data layout" for
> the triple."
>> 
>> 
>> Thanks for clarifying this. So, we are guaranteed to DL even without
> datalayout in the textual IR. However, this doesn't mean that we can always
> get the non-zero from DL.getLargestLegalIntTypeSizeInBits().  As I test, we
> can use an empty datalayout in IR like : target datalayout="".
> 
> I feel you are speculating, and haven't really tried the effects of what
> your describing, neither look at the code that constructs a DataLayout.
> Writing this in textual IR is identical to not write anything.
> 
> 
>> 
>>> Wouldn't DL.getLargestLegalIntTypeSizeInBits() == 0 imply that you can
> have icmp or select? Hence almost nothing in llvm would work?
>> 
>> 
>> Although we can make DL.getLargestLegalIntTypeSizeInBits() return  0,
> 
> Please write a test case.
> 
> 
>> I also doubt when this is meaningful. If this doesn't make sense, I 
>> will add  assert in getLargestLegalIntTypeSizeInBits().
> 
> I don't think such an assert makes sense here, on a function that is
> frequently called.
> If you insist on verifying properties on the DataLayout, do it in reset().
> 
>> Can anyone give us any feedback if there is any situation where we need
> to consider getLargestLegalIntTypeSizeInBits() == 0 ?  As far as I test, I
> didn't see any unit test failure with the assert in
> getLargestLegalIntTypeSizeInBits() == 0.
> 
> Not surprising...
> 
> 
> --
> Mehdi
> 
> 



More information about the llvm-commits mailing list