[PATCH] D40670: Let Alloca treated as nonnull for any alloca addr space value

[Yaxun Liu via Phabricator via llvm-commits]

yaxunl added a comment.

In https://reviews.llvm.org/D40670#944760, @silvas wrote:

> In https://reviews.llvm.org/D40670#942340, @yaxunl wrote:
>
> > In https://reviews.llvm.org/D40670#942326, @arsenm wrote:
> >
> > > In https://reviews.llvm.org/D40670#942316, @yaxunl wrote:
> > >
> > > > In https://reviews.llvm.org/D40670#942232, @yaxunl wrote:
> > > >
> > > > > In https://reviews.llvm.org/D40670#941244, @nlopes wrote:
> > > > >
> > > > > > This change is incorrect.  null can be a valid pointer in a non-0 address space, and alloca may return it.
> > > > > >  If your target's address space guarantees that alloca doesn't return null, then we can probably make this target-dependent. But we cannot simply make it unconditional; that's not correct.
> > > > >
> > > > >
> > > > > If whether alloca inst can be zero depending on target, then we need to make it target dependent. I will see if I can add this to TargetTransformInfo.
> > > >
> > > >
> > > > Well, this will incur lots of interface changes. Essentially all value tracking functions and passes relying on value tracking will require TargetTransformInfo. Do we want to do that?
> > > >
> > > > On the other hand, on which specific target alloca inst could be null? As Matt said, alloca cannot be used to represent malloc, why alloca inst could be null?
> > >
> > >
> > > AMDGPU currently has a workaround to avoid alloca ever returning 0. 0 is a valid pointer though. What we really want to represent is that alloca never returns an invalid pointer, not that it never has a 0 value
> >
> >
> > If the nullptr is not zero, Clang will generate proper instruction for comparing with non-zero nullptr value, so it is not an issue.
> >
> > For the issue which this patch is trying to solve, we need to know if alloca can be zero to simplify icmp instruction. Knowing alloca inst is valid pointer is not sufficient to simplify icmp instruction.
> >
> > So far, I do not see a specific target on which alloca inst could be zero. As an instruction used so extensively, I think it is reasonable to assume any alloca inst is non-zero, no matter what addr space it uses.
>
>
> FWIW I work on an out of tree target where an alloca can have a value that is numerically 0. I expect many accelerators are in the same situation.
>
> Out of curiosity, does the OpenCL spec say anything about the numerical value of the address of __local declarations (which is the only thing where clang will generate an alloca with non-zero address space IIRC) (of course, clang isn't the only frontend but it is at least a useful sanity check).


The LLVM language manual (https://llvm.org/docs/LangRef.html#alloca-instruction) said:

The ‘alloca‘ instruction allocates memory on the stack frame of the currently executing function, to be automatically released when this function returns to its caller. The object is always allocated in the address space for allocas indicated in the datalayout.

Therefore alloca instruction is not supposed to be used for allocating memory other than private memory in OpenCL. The target datalayout specifies the address space used by alloca.

Also, non-zero alloca address space has already been used by amdgcn target in LLVM/clang trunk. For amdgcn---amdgiz triple, alloca address space is 5. amdgcn---amdgiz target uses 5 as alloca address space because it needs to use address space 0 as generic address space for better support C++-based kernel languages.

Non-zero alloca address space is no special from zero alloca address space. The alloca instruction in non-zero alloca address space still allocates memory on stack.


https://reviews.llvm.org/D40670