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

[Matt Arsenault via llvm-dev]

> On Dec 15, 2017, at 01:20, Hal Finkel <hfinkel at anl.gov> wrote:
> 
> Okay. That's certainly a separate discussion. For the purpose of this question I mean null as zero. Can you have dereferenceable pointers, with a value of zero when converted to an integer, in that address space? Or are you interested only in saying that alloca never produces pointers with a value of zero when converted to an integer?

I think this is the problem we actually want to be solving. On AMDGPU the stack grows up and naturally begins at 0. 0 is a valid, dereferencable pointer. We have a workaround now where we won’t allocate a user object at offset 0, but that’s mostly just because before when alloca had to be in the default address space this was required. I would rather not do the work to push this back in that direction. The point of this patch originally I thought was to fix tests which are comparing against null pointers. We really want them to be checking against the true invalid pointer value.

-Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171215/bac562c5/attachment-0001.html>