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

[Hal Finkel via llvm-dev]

On 12/15/2017 01:34 AM, Sean Silva wrote:
>
>
> On Dec 14, 2017 10:21 PM, "Hal Finkel via llvm-dev" 
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>
>
>     On 12/14/2017 11:14 PM, Matt Arsenault wrote:
>>
>>
>>>     On Dec 14, 2017, at 20:28, Hal Finkel via llvm-dev
>>>     <llvm-dev at lists.llvm.org <mailto: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.
>
>     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?
>
>
> FWIW on Pixel Visual Core, we have on-chip memories for which the 
> pointer with numerical value zero is a valid location (and it is 
> natural to model these as allocas).
>
> As I've come to learn, it's actually difficult for the hardware folks 
> to make 0 *not* be valid since the address decoders selecting which 
> word from a memory should be read out naturally take 0 to N as input. 
> (I.e. at the end of the day everything is actually a natural 0-based 
> index into an array)
>
> The only case I can think of where it is convenient to make 0 be 
> invalid is when you are dealing with a relatively sparsely populated 
> memory map (either virtual or hardcoded as in a microcontroller) and 
> you can simply avoid putting something at 0. But that's more about the 
> logic that looks at the high bits of the address to determine which 
> mapping in the memory map is being accessed.
>
> So I assume that it most of the time when you have explicitly 
> addressed memories that are not part of a larger linear memory map, 
> the numerically 0 pointer will actually be valid. On-chip scratchpad 
> memories on accelerators are probably going to be a common case of 
> this (such as the AMDGPU LDS in this thread I presume).

Certainly. I can imagine, however, cases where zero is a valid address 
in general, but will never be a stack-allocated address (e.g., because 
your stack grows down, so 0 is the very last byte of the possible stack 
in that address space, and the stack just can't grow that far because 
there's other data there).

  -Hal

>
> -- Sean Silva
>
>
>     Thanks again,
>     Hal
>
>>
>>     -Matt
>
>     -- 
>     Hal Finkel
>     Lead, Compiler Technology and Programming Languages
>     Leadership Computing Facility
>     Argonne National Laboratory
>
>
>     _______________________________________________
>     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
>     <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/20171215/e7320663/attachment.html>