llvm dev - Dec 2017 - [RFC] Add TargetTransformInfo::isAllocaPtrValueNonZero and let ValueTracking depend on TargetTransformInfo

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171214/00763b7a/attachment.html>

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
> 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/c9834870/attachment.html>

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>