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

> On Dec 14, 2017, at 20:28, Hal Finkel via llvm-dev <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.

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

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?

Thanks again,
Hal
>
> -Matt
-- 
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/58b5336e/attachment.html>

On Dec 14, 2017 10:21 PM, "Hal Finkel via llvm-dev" <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>
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).

-- 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
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171214/82094b37/attachment.html>

> 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>