[llvm-dev] [RFC] Add TargetTransformInfo::isAllocaPtrValueNonZero and let ValueTracking depend on TargetTransformInfo
Hal Finkel via llvm-dev
llvm-dev at lists.llvm.org
Thu Dec 14 13:06:14 PST 2017
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).
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.
> As a result, passes using ValueTracking will require TargetTransformInfo.
> Comments are welcome.
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev