Liu, Yaxun (Sam) via llvm-dev
2017-Dec-14 21:49 UTC
[llvm-dev] [RFC] Add TargetTransformInfo::isAllocaPtrValueNonZero and let ValueTracking depend on TargetTransformInfo
Hal, Thanks for your suggestion. I think that makes sense. Currently, non-zero alloca address space is already represented by data layout, e.g., the last component of the data layout of amdgcn---amdgiz target is -A5, which means alloca is in address space 5. How about adding a letter z to -A5 to indicate alloca may have zero value? i.e. -A5 means alloca is in address space 5 and always has non-zero value, -A5z means alloca is in address space 5 and may have zero value. Then we can add function DataLayout::isAllocaPtrValueNonZero() to check whether alloca always has non-zero value. Sam From: Hal Finkel [mailto:hfinkel at anl.gov] Sent: Thursday, December 14, 2017 4:06 PM To: Liu, Yaxun (Sam) <Yaxun.Liu at amd.com>; llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] [RFC] Add TargetTransformInfo::isAllocaPtrValueNonZero and let ValueTracking depend on TargetTransformInfo Hi, Sam, Our general design has been that TTI is for cost modeling, not for providing semantic information. This piece of information can go in DataLayout, and I think we should put it there. Especially given that this affects our canonicalization process, or preference should be to avoid TTI. The more than TTI affects our canonical form, the more fragmented it becomes, and the harder it is to understand. Putting it in DataLayout also prevents us from having to propagate TTI into a bunch of ValueTracking functions (and maximally retains our ability to process IR without backends compiled in). Thanks again, Hal On 12/14/2017 02:32 PM, Liu, Yaxun (Sam) via llvm-dev wrote: Some optimizations depend on whether alloca instruction always has non-zero value. Currently, this checking is done by isKnownNonZero() in ValueTracking, and it assumes alloca in address space 0 always has non-zero value but alloca in non-zero address spaces does not always have non-zero value. However, this assumption is incorrect for certain targets. For example, amdgcn---amdgiz target has alloca in address space 5, and its alloca always has non-zero value. This assumption causes some optimizations disabled for amdgcn---amdgiz target. After discussions at https://reviews.llvm.org/D40670, I propose to introduce TargetTransformInfo::isAllocaPtrValueNonZero for representing whether alloca instruction always has non-zero value, and add a TargetTransformInfo argument to ValueTracking functions e.g. isKnownNonZero(). As a result, passes using ValueTracking will require TargetTransformInfo. Comments are welcome. Thanks. Sam _______________________________________________ LLVM Developers mailing list llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev -- Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171214/1e367921/attachment.html>
Hal Finkel via llvm-dev
2017-Dec-15 01:28 UTC
[llvm-dev] [RFC] Add TargetTransformInfo::isAllocaPtrValueNonZero and let ValueTracking depend on TargetTransformInfo
On 12/14/2017 03:49 PM, Liu, Yaxun (Sam) wrote:> > Hal, > > Thanks for your suggestion. I think that makes sense. > > Currently, non-zero alloca address space is already represented by > data layout, e.g., the last component of the data layout of > amdgcn---amdgiz target is -A5, which means alloca is in address space > 5. How about adding a letter z to -A5 to indicate alloca may have zero > value? i.e. -A5 means alloca is in address space 5 and always has > non-zero value, -A5z means alloca is in address space 5 and may have > zero value. > > Then we can add function DataLayout::isAllocaPtrValueNonZero() to > check whether alloca always has non-zero value. >I believe that we should phrase this in a way not directly connected to alloca, but to dereferenceability. We currently assume that dereferenceable pointers can't be null in address space 0, but we don't make that assumption about other address spaces (where null might be a valid address). I think that we should address this problem, and then simply apply the result to alloca. We currently have, for address spaces:> |p[n]:<size>:<abi>:<pref>| > This specifies the/size/of a pointer and > its|<abi>|and|<pref>|erred alignments for address space|n|. All > sizes are in bits. The address space,|n|, is optional, and if not > specified, denotes the default address space 0. The value > of|n|must be in the range [1,2^23).How about we allow the addition of 'n' (for non-zero) after the address-space number. This, implied by default for address space zero but not others, will imply that dereferenceable address are non-null. We can then apply this in isKnownNonZero in the places where we currently check for address space zero. Would that address your use case? Or can you have null dereferenceable pointers in that address space, just not ones from alloca? -Hal> Sam > > *From:*Hal Finkel [mailto:hfinkel at anl.gov] > *Sent:* Thursday, December 14, 2017 4:06 PM > *To:* Liu, Yaxun (Sam) <Yaxun.Liu at amd.com>; llvm-dev > <llvm-dev at lists.llvm.org> > *Subject:* Re: [llvm-dev] [RFC] Add > TargetTransformInfo::isAllocaPtrValueNonZero and let ValueTracking > depend on TargetTransformInfo > > Hi, Sam, > > Our general design has been that TTI is for cost modeling, not for > providing semantic information. This piece of information can go in > DataLayout, and I think we should put it there. Especially given that > this affects our canonicalization process, or preference should be to > avoid TTI. The more than TTI affects our canonical form, the more > fragmented it becomes, and the harder it is to understand. Putting it > in DataLayout also prevents us from having to propagate TTI into a > bunch of ValueTracking functions (and maximally retains our ability to > process IR without backends compiled in). > > Thanks again, > Hal > > On 12/14/2017 02:32 PM, Liu, Yaxun (Sam) via llvm-dev wrote: > > Some optimizations depend on whether alloca instruction always has > non-zero value. Currently, this checking is done by > isKnownNonZero() in ValueTracking, and it assumes alloca in > address space 0 always has non-zero value but alloca in non-zero > address spaces does not always have non-zero value. > > However, this assumption is incorrect for certain targets. For > example, amdgcn---amdgiz target has alloca in address space 5, and > its alloca always has non-zero value. This assumption causes some > optimizations disabled for amdgcn---amdgiz target. > > After discussions at https://reviews.llvm.org/D40670 > <https://reviews.llvm.org/D40670>, I propose to introduce > TargetTransformInfo::isAllocaPtrValueNonZero for representing > whether alloca instruction always has non-zero value, and add a > TargetTransformInfo argument to ValueTracking functions e.g. > isKnownNonZero(). > > As a result, passes using ValueTracking will require > TargetTransformInfo. > > Comments are welcome. > > Thanks. > > Sam > > > > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > -- > Hal Finkel > Lead, Compiler Technology and Programming Languages > Leadership Computing Facility > Argonne National Laboratory-- Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171214/34bbec30/attachment.html>
Liu, Yaxun (Sam) via llvm-dev
2017-Dec-15 02:31 UTC
[llvm-dev] [RFC] Add TargetTransformInfo::isAllocaPtrValueNonZero and let ValueTracking depend on TargetTransformInfo
This should work for me. I will check with Nuno Lopes whether this works for him. Thanks. Sam From: Hal Finkel [mailto:hfinkel at anl.gov] Sent: Thursday, December 14, 2017 8:29 PM To: Liu, Yaxun (Sam) <Yaxun.Liu at amd.com>; llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] [RFC] Add TargetTransformInfo::isAllocaPtrValueNonZero and let ValueTracking depend on TargetTransformInfo On 12/14/2017 03:49 PM, Liu, Yaxun (Sam) wrote: Hal, Thanks for your suggestion. I think that makes sense. Currently, non-zero alloca address space is already represented by data layout, e.g., the last component of the data layout of amdgcn---amdgiz target is -A5, which means alloca is in address space 5. How about adding a letter z to -A5 to indicate alloca may have zero value? i.e. -A5 means alloca is in address space 5 and always has non-zero value, -A5z means alloca is in address space 5 and may have zero value. Then we can add function DataLayout::isAllocaPtrValueNonZero() to check whether alloca always has non-zero value. I believe that we should phrase this in a way not directly connected to alloca, but to dereferenceability. We currently assume that dereferenceable pointers can't be null in address space 0, but we don't make that assumption about other address spaces (where null might be a valid address). I think that we should address this problem, and then simply apply the result to alloca. We currently have, for address spaces: p[n]:<size>:<abi>:<pref> This specifies the size of a pointer and its <abi> and <pref>erred alignments for address space n. All sizes are in bits. The address space, n, is optional, and if not specified, denotes the default address space 0. The value of n must be in the range [1,2^23). How about we allow the addition of 'n' (for non-zero) after the address-space number. This, implied by default for address space zero but not others, will imply that dereferenceable address are non-null. We can then apply this in isKnownNonZero in the places where we currently check for address space zero. Would that address your use case? Or can you have null dereferenceable pointers in that address space, just not ones from alloca? -Hal Sam From: Hal Finkel [mailto:hfinkel at anl.gov] Sent: Thursday, December 14, 2017 4:06 PM To: Liu, Yaxun (Sam) <Yaxun.Liu at amd.com><mailto:Yaxun.Liu at amd.com>; llvm-dev <llvm-dev at lists.llvm.org><mailto:llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] [RFC] Add TargetTransformInfo::isAllocaPtrValueNonZero and let ValueTracking depend on TargetTransformInfo Hi, Sam, Our general design has been that TTI is for cost modeling, not for providing semantic information. This piece of information can go in DataLayout, and I think we should put it there. Especially given that this affects our canonicalization process, or preference should be to avoid TTI. The more than TTI affects our canonical form, the more fragmented it becomes, and the harder it is to understand. Putting it in DataLayout also prevents us from having to propagate TTI into a bunch of ValueTracking functions (and maximally retains our ability to process IR without backends compiled in). Thanks again, Hal On 12/14/2017 02:32 PM, Liu, Yaxun (Sam) via llvm-dev wrote: Some optimizations depend on whether alloca instruction always has non-zero value. Currently, this checking is done by isKnownNonZero() in ValueTracking, and it assumes alloca in address space 0 always has non-zero value but alloca in non-zero address spaces does not always have non-zero value. However, this assumption is incorrect for certain targets. For example, amdgcn---amdgiz target has alloca in address space 5, and its alloca always has non-zero value. This assumption causes some optimizations disabled for amdgcn---amdgiz target. After discussions at https://reviews.llvm.org/D40670, I propose to introduce TargetTransformInfo::isAllocaPtrValueNonZero for representing whether alloca instruction always has non-zero value, and add a TargetTransformInfo argument to ValueTracking functions e.g. isKnownNonZero(). As a result, passes using ValueTracking will require TargetTransformInfo. Comments are welcome. Thanks. Sam _______________________________________________ LLVM Developers mailing list llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev -- Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory -- Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171215/b150c1fc/attachment.html>
Matt Arsenault via llvm-dev
2017-Dec-15 05:14 UTC
[llvm-dev] [RFC] Add TargetTransformInfo::isAllocaPtrValueNonZero and let ValueTracking depend on TargetTransformInfo
> On Dec 14, 2017, at 20:28, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Would that address your use case? Or can you have null dereferenceable pointers in that address space, just not ones from alloca?I would like to clarify what “null” means exactly. One related thing I would like in the future is for the DataLayout to specify what numeric value is the invalid, non-dereferencalbe pointer. i.e. the invalid pointer does is a some non-0 bit pattern like -1. -Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171215/d29fb446/attachment.html>