llvm dev - Oct 2016 - RFC: Absolute or "fixed address" symbols as immediate operands

Responding to both of your emails in one, sorry for the delay:
> On Oct 25, 2016, at 11:20 AM, Peter Collingbourne <peter at
pcc.me.uk> wrote:
> I think there are a couple of additional considerations we should make
here:
> What are we trying to model? To me it's clear that GlobalConstant is
for modelling integers, not pointers. That alone may not necessarily be enough
to motivate a representational change, but…
I understand where you’re coming from, but I think we’re modeling three
different things, and disagreeing about how to clump them together.  The three
things I see in flight are:

1) typical globals that are laid out in some unknown way in the address space.
2) globals that may be tied to a specific knowable address range due to a
limited compilation model (e.g. a deeply embedded core) that fits into an
immedaite range (e.g. 0…255, 0…65536, etc).
3) Immediates that are treated as symbolic for CFI’s perspective (so they can’t
just be used as a literal immediate) that are resolved at link time, but are
known to have limited range.

There is also "4) immediates with an obvious known value”, but those are
obviously ConstantInt’s and not interesting to discuss here.

The design I’m arguing for is to clump #2 and #3 into the same group.  This can
be done one of two different ways, but both ways use the same “declaration side”
reference, which has a !range metadata attached to it.  The three approaches I
see are:

a) Introduce a new GlobalConstant definition, whose value is the concrete
address that the linker should resolve.
b) Use an alias as the definition, whose body is a ptrtoint constant of the same
value.
c) Use a zero size globalvariable with a range metadata specifying the exact
address decided.

I’m not very knowledgable about why approach b won’t work, but if it could, it
seems preferable because it fits in with our current model.  After that,
approach C seems like a nice fallback because it again doesn’t require major
extensions to our model.  Finally, approach A seems like the most explicit
model, but has the disadvantage of introducing a new IR concept that will be
rarely used (and thus prone to bugs due to it not being widely tested).
> If we make our representation fit the model, does that improve the quality
of the code? There's clearly been a long standing assumption that
GlobalValues are of pointer type. Breaking that assumption has in fact found
potential bugs (see e.g. my changes to ValueTracking.cpp in D25930, as well as
D25917 which was a requirement for the representational change), and seems like
it may help prevent bugs in the future, so I'd say that the answer is most
likely yes.
I’d argue the other side of it.  The quality of the code is higher if we have
invariants (like all globals are pointers) because that simplifies assumptions
by eliminating cases where “is a pointer” appears to be true, but isn’t actually
true in all cases.  I’m not an expert on CFI or how widely it will ultimately
impact the compiler hacker consciousness, but I’m pretty sure that the current
model for globals and functions will remain more prominent.  If you choose to
break this invariant, you’ll be continually swimming upstream against
assumptions made throughout the compiler, both in code written today but also in
code written in the future.

On Oct 25, 2016, at 6:52 PM, Peter Collingbourne <peter at pcc.me.uk>
wrote:
> 
> So, to summarise the overall consensus on this thread:
> - We should introduce a GlobalConstant class which supports definitions and
declarations
Why would globalconstant need to support declarations?  Seems like an external
global should be able to handle this case.
> - It should derive from GlobalValue
> - No type changes for GlobalValue (i.e. still required to be pointer type)
> - To communicate the range we should use !range metadata and support it on
GlobalConstant as well as GlobalVariable
> 
> Although I am not convinced that this is the right representation I appear
to be in the minority here, so if this seems reasonable to folks I will go ahead
and implement it.
I’m not trying to steamroll you over: what is your specific concern?

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161025/1d590327/attachment.html>

On Tue, Oct 25, 2016 at 10:48 PM, Chris Lattner <clattner at apple.com>
wrote:
> Responding to both of your emails in one, sorry for the delay:
>
> On Oct 25, 2016, at 11:20 AM, Peter Collingbourne <peter at
pcc.me.uk> wrote:
> I think there are a couple of additional considerations we should make
> here:
>
>    - What are we trying to model? To me it's clear that GlobalConstant
is
>    for modelling integers, not pointers. That alone may not necessarily be
>    enough to motivate a representational change, but…
>
> I understand where you’re coming from, but I think we’re modeling three
> different things, and disagreeing about how to clump them together.  The
> three things I see in flight are:
>
> 1) typical globals that are laid out in some unknown way in the address
> space.
> 2) globals that may be tied to a specific knowable address range due to a
> limited compilation model (e.g. a deeply embedded core) that fits into an
> immedaite range (e.g. 0…255, 0…65536, etc).
> 3) Immediates that are treated as symbolic for CFI’s perspective (so they
> can’t just be used as a literal immediate) that are resolved at link time,
> but are known to have limited range.
>
> There is also "4) immediates with an obvious known value”, but those
are
> obviously ConstantInt’s and not interesting to discuss here.
>
> The design I’m arguing for is to clump #2 and #3 into the same group.
>
I am not sure if this is sound if we want the no-alias assumption (see also
below) to hold for #2 but not for #3.

>   This can be done one of two different ways, but both ways use the same
> “declaration side” reference, which has a !range metadata attached to it.
> The three approaches I see are:
>
> a) Introduce a new GlobalConstant definition, whose value is the concrete
> address that the linker should resolve.
> b) Use an alias as the definition, whose body is a ptrtoint constant of
> the same value.
> c) Use a zero size globalvariable with a range metadata specifying the
> exact address decided.
>
> I’m not very knowledgable about why approach b won’t work, but if it
> could, it seems preferable because it fits in with our current model.
>
b would work in that it would give us the right bits in the object file,
but it would be a little odd to use a different type for declarations as
for definitions. That said, I don't have a strong objection to it.

After that, approach C seems like a nice fallback because it again
doesn’t
> require major extensions to our model.  Finally, approach A seems like the
> most explicit model, but has the disadvantage of introducing a new IR
> concept that will be rarely used (and thus prone to bugs due to it not
> being widely tested).
>
>
>    - If we make our representation fit the model, does that improve the
>    quality of the code? There's clearly been a long standing assumption
that
>    GlobalValues are of pointer type. Breaking that assumption has in fact
>    found potential bugs (see e.g. my changes to ValueTracking.cpp in
D25930,
>    as well as D25917 which was a requirement for the representational
change),
>    and seems like it may help prevent bugs in the future, so I'd say
that the
>    answer is most likely yes.
>
> I’d argue the other side of it.  The quality of the code is higher if we
> have invariants (like all globals are pointers) because that simplifies
> assumptions by eliminating cases where “is a pointer” appears to be true,
> but isn’t actually true in all cases.
>
We'd still be able to have an "is a pointer" invariant, but on a
specific
subset of globals. In practice I'd expect that a frontend that chooses to
make that assumption can use GlobalPointer in place of GlobalValue.

> I’m not an expert on CFI or how widely it will ultimately impact the
> compiler hacker consciousness, but I’m pretty sure that the current model
> for globals and functions will remain more prominent.  If you choose to
> break this invariant, you’ll be continually swimming upstream against
> assumptions made throughout the compiler, both in code written today but
> also in code written in the future.
>
I think this is as least as likely to be true in the case where we do
choose to use pointer modelling, as those assumptions are going to exist no
matter what representation we choose, at least until they are found and
fixed. The difference is that when assumptions are broken, they will be
more likely to break loudly (e.g. casting assertion failures) as opposed to
subtly as could have happened with the non-null assumption in
ValueTracking. CFI will have full integration testing on supported
platforms, and has been deployed in Chrome on Linux since August, so at
least the important known use cases should continue to work. The
unimportant use cases may not, but that seems like it could be the case for
any IR feature.

You can see for yourself from D25930 that (relatively speaking) very few
places in the entire codebase need to care about this at the type system
level. I was in fact surprised at how little code I needed to change for an
assumption that has apparently existed since 2001. Granted this doesn't
reveal non-type-system-level assumptions, but as I mentioned those
assumptions would exist anyway.

On Oct 25, 2016, at 6:52 PM, Peter Collingbourne <peter at pcc.me.uk>
wrote:
>
>
> So, to summarise the overall consensus on this thread:
> - We should introduce a GlobalConstant class which supports definitions
> and declarations
>
>
> Why would globalconstant need to support declarations?  Seems like an
> external global should be able to handle this case.
>
An external globalvariable? I am not sure how to reconcile this with your
comment on D25878:
> LLVM IR global variables should always be assumable that they don't
alias.
I'm thinking of the case where we have two globalconstants which happen to
have the same value.

- It should derive from GlobalValue
> - No type changes for GlobalValue (i.e. still required to be pointer type)
> - To communicate the range we should use !range metadata and support it on
> GlobalConstant as well as GlobalVariable
>
> Although I am not convinced that this is the right representation I appear
> to be in the minority here, so if this seems reasonable to folks I will go
> ahead and implement it.
>
>
> I’m not trying to steamroll you over: what is your specific concern?
>
My specific concern is pointer modeling. I think Chandler put it well in
his most recent mail.

Thanks,
-- 
-- 
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161026/cf121ca4/attachment.html>

To what Reid said, I'm not really worried about impact on the middle end of
any of this. We can handle the code changes, etc.

I agree with Chris about what we're trading off here:

On Tue, Oct 25, 2016 at 10:48 PM Chris Lattner via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> I’d argue the other side of it.  The quality of the code is higher if we
> have invariants (like all globals are pointers) because that simplifies
> assumptions by eliminating cases where “is a pointer” appears to be true,
> but isn’t actually true in all cases.  I’m not an expert on CFI or how
> widely it will ultimately impact the compiler hacker consciousness, but I’m
> pretty sure that the current model for globals and functions will remain
> more prominent.  If you choose to break this invariant, you’ll be
> continually swimming upstream against assumptions made throughout the
> compiler, both in code written today but also in code written in the
future.
>
I agree that mental assumptions the developers on the middle end hold are
the primary challenge here. But I think we are going to run into challenges
either way.

If the type of these entities is an integer, we will have a non-pointer
global, yes. But as Peter points out, this is caught effectively by asserts
in the cast infrastructure and other programming aids. Essentially, the
checking of LLVM's type system helps protect the random middle end
developer from getting this wrong.

On the other hand, if the type of these entities remains consistently
pointers, we will still break assumptions that middle end developers
routinely make about pointers to globals:
- They aren't dereferencable
- They aren't aligned
- They may be null
- The difference between them might not be representable in a
pointer-sized-integer

In essence, their *values* won't behave like pointers even if we make the
LLVM IR type a pointer. So the wrong assumption will shift from an IR type
system error to a value error. I would generally much prefer the LLVM IR's
type system catch this kind of error. Even if these wrong assumptions about
the values are much less common, I would prefer the more common but easily
caught type system error.


To Rafael's point, while I agree that at the object file level these are
indeed addresses, I personally am much more interested in the IR modeling
things in ways convenient to the middle end optimizer than to the linker.
And there, the above seems like the dominant tradeoff.


Anyways, if Reid, Chris, and Rafael all strongly feel like keeping the
types consistent is actually the right tradeoff, I don't want to stand in
the way. So far, I just find the arguments for why this is the right
tradeoff unconvincing.

-Chandler


PS: In case it isn't clear, I'm totally fine with having the range
metadata
available for the case where globals are mapped into very specific regions
for bare metal / embedded architectures, but *should* be treated as actual
addresses of objects that can be loaded and stored through. And those seem
unambiguously like they should be pointers. But that seems like a separate
use case and discussion...
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161026/f22db89c/attachment.html>

On 10/26/2016 10:10 AM, Chandler Carruth via llvm-dev
wrote:
> To what Reid said, I'm not really worried about impact on the middle 
> end of any of this. We can handle the code changes, etc.
>
> I agree with Chris about what we're trading off here:
>
> On Tue, Oct 25, 2016 at 10:48 PM Chris Lattner via llvm-dev 
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>> wrote:
>
>     I’d argue the other side of it. The quality of the code is higher
>     if we have invariants (like all globals are pointers) because that
>     simplifies assumptions by eliminating cases where “is a pointer”
>     appears to be true, but isn’t actually true in all cases.  I’m not
>     an expert on CFI or how widely it will ultimately impact the
>     compiler hacker consciousness, but I’m pretty sure that the
>     current model for globals and functions will remain more
>     prominent.  If you choose to break this invariant, you’ll be
>     continually swimming upstream against assumptions made throughout
>     the compiler, both in code written today but also in code written
>     in the future.
>
>
> I agree that mental assumptions the developers on the middle end hold 
> are the primary challenge here. But I think we are going to run into 
> challenges either way.
>
> If the type of these entities is an integer, we will have a 
> non-pointer global, yes. But as Peter points out, this is caught 
> effectively by asserts in the cast infrastructure and other 
> programming aids. Essentially, the checking of LLVM's type system 
> helps protect the random middle end developer from getting this wrong.
>
> On the other hand, if the type of these entities remains consistently 
> pointers, we will still break assumptions that middle end developers 
> routinely make about pointers to globals:
> - They aren't dereferencable
> - They aren't aligned
> - They may be null
> - The difference between them might not be representable in a 
> pointer-sized-integer
>
> In essence, their *values* won't behave like pointers even if we make 
> the LLVM IR type a pointer. So the wrong assumption will shift from an 
> IR type system error to a value error. I would generally much prefer 
> the LLVM IR's type system catch this kind of error. Even if these 
> wrong assumptions about the values are much less common, I would 
> prefer the more common but easily caught type system error.
>
>
> To Rafael's point, while I agree that at the object file level these 
> are indeed addresses, I personally am much more interested in the IR 
> modeling things in ways convenient to the middle end optimizer than to 
> the linker. And there, the above seems like the dominant tradeoff.
>
>
> Anyways, if Reid, Chris, and Rafael all strongly feel like keeping the 
> types consistent is actually the right tradeoff, I don't want to stand 
> in the way. So far, I just find the arguments for why this is the 
> right tradeoff unconvincing.
I agree with Chandler here on pretty much all of this (including the 
willingness to be ignored if consensus goes the other
way.)
>
> -Chandler
>
>
> PS: In case it isn't clear, I'm totally fine with having the range 
> metadata available for the case where globals are mapped into very 
> specific regions for bare metal / embedded architectures, but *should* 
> be treated as actual addresses of objects that can be loaded and 
> stored through. And those seem unambiguously like they should be 
> pointers. But that seems like a separate use case and discussion...
>
>
> _______________________________________________
> 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/20161026/7b14d16e/attachment.html>

On Oct 26, 2016, at 10:10 AM, Chandler Carruth <chandlerc at google.com>
wrote:
> 
> To what Reid said, I'm not really worried about impact on the middle
end of any of this. We can handle the code changes, etc.
> 
> I agree with Chris about what we're trading off here:
> 
> On Tue, Oct 25, 2016 at 10:48 PM Chris Lattner via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> I’d argue the other side of it.  The quality of the code is higher if we
have invariants (like all globals are pointers) because that simplifies
assumptions by eliminating cases where “is a pointer” appears to be true, but
isn’t actually true in all cases.  I’m not an expert on CFI or how widely it
will ultimately impact the compiler hacker consciousness, but I’m pretty sure
that the current model for globals and functions will remain more prominent.  If
you choose to break this invariant, you’ll be continually swimming upstream
against assumptions made throughout the compiler, both in code written today but
also in code written in the future.
> 
> I agree that mental assumptions the developers on the middle end hold are
the primary challenge here. But I think we are going to run into challenges
either way.
> 
> If the type of these entities is an integer, we will have a non-pointer
global, yes. But as Peter points out, this is caught effectively by asserts in
the cast infrastructure and other programming aids. Essentially, the checking of
LLVM's type system helps protect the random middle end developer from
getting this wrong.
> 
> On the other hand, if the type of these entities remains consistently
pointers, we will still break assumptions that middle end developers routinely
make about pointers to globals:
> - They aren't dereferencable
> - They aren't aligned
> - They may be null
> - The difference between them might not be representable in a
pointer-sized-integer
Aren’t all these true of “inttoptr’d” integer constants already?  This is
already part of the model for things that are PointerType’s, so I don’t see how
either resolution would change that.

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161026/958018e8/attachment.html>

On Oct 26, 2016, at 1:34 AM, Peter Collingbourne <peter at pcc.me.uk>
wrote:
> On Tue, Oct 25, 2016 at 10:48 PM, Chris Lattner <clattner at apple.com
<mailto:clattner at apple.com>> wrote:
> Responding to both of your emails in one, sorry for the delay:
> 
>> On Oct 25, 2016, at 11:20 AM, Peter Collingbourne <peter at
pcc.me.uk <mailto:peter at pcc.me.uk>> wrote:
>> I think there are a couple of additional considerations we should make
here:
>> What are we trying to model? To me it's clear that GlobalConstant
is for modelling integers, not pointers. That alone may not necessarily be
enough to motivate a representational change, but…
> I understand where you’re coming from, but I think we’re modeling three
different things, and disagreeing about how to clump them together.  The three
things I see in flight are:
> 
> 1) typical globals that are laid out in some unknown way in the address
space.
> 2) globals that may be tied to a specific knowable address range due to a
limited compilation model (e.g. a deeply embedded core) that fits into an
immedaite range (e.g. 0…255, 0…65536, etc).
> 3) Immediates that are treated as symbolic for CFI’s perspective (so they
can’t just be used as a literal immediate) that are resolved at link time, but
are known to have limited range.
> 
> There is also "4) immediates with an obvious known value”, but those
are obviously ConstantInt’s and not interesting to discuss here.
> 
> The design I’m arguing for is to clump #2 and #3 into the same group.
> 
> I am not sure if this is sound if we want the no-alias assumption (see also
below) to hold for #2 but not for #3.
>  
>   This can be done one of two different ways, but both ways use the same
“declaration side” reference, which has a !range metadata attached to it.  The
three approaches I see are:
> 
> a) Introduce a new GlobalConstant definition, whose value is the concrete
address that the linker should resolve.
> b) Use an alias as the definition, whose body is a ptrtoint constant of the
same value.
> c) Use a zero size globalvariable with a range metadata specifying the
exact address decided.
> 
> I’m not very knowledgable about why approach b won’t work, but if it could,
it seems preferable because it fits in with our current model.
> 
> b would work in that it would give us the right bits in the object file,
but it would be a little odd to use a different type for declarations as for
definitions. That said, I don't have a strong objection to it.
I can understand what you’re saying here, but this is already the case for
aliases.  You can never have a “declaration side” for an alias that is an alias
(you have to use an external global variable or a function with no body).

From the discussion over the last day it sounds to me that “b” is the best
approach, except for the (significant) annoyance that these things can be
possibly aliased.  However, I don’t understand how this works in practice today
for aliases.  By their very name, they are *all about* introducing aliases, so
how is AA allowed to assume that two external global variable references are
unaliased anyway?  One may be resolved as an alias to the other afterall,
completely independent of your proposal.

-Chris


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161026/8fc5b1d0/attachment.html>

Re-adding list.

On Wed, Oct 26, 2016 at 10:38 PM, Peter Collingbourne <peter at pcc.me.uk>
wrote:
>
>
> On Wed, Oct 26, 2016 at 9:43 PM, Chris Lattner <clattner at
apple.com> wrote:
>
>> On Oct 26, 2016, at 10:10 AM, Chandler Carruth <chandlerc at
google.com>
>> wrote:
>>
>>
>> To what Reid said, I'm not really worried about impact on the
middle end
>> of any of this. We can handle the code changes, etc.
>>
>> I agree with Chris about what we're trading off here:
>>
>> On Tue, Oct 25, 2016 at 10:48 PM Chris Lattner via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> I’d argue the other side of it.  The quality of the code is higher
if we
>>> have invariants (like all globals are pointers) because that
simplifies
>>> assumptions by eliminating cases where “is a pointer” appears to be
true,
>>> but isn’t actually true in all cases.  I’m not an expert on CFI or
how
>>> widely it will ultimately impact the compiler hacker consciousness,
but I’m
>>> pretty sure that the current model for globals and functions will
remain
>>> more prominent.  If you choose to break this invariant, you’ll be
>>> continually swimming upstream against assumptions made throughout
the
>>> compiler, both in code written today but also in code written in
the future.
>>>
>>
>> I agree that mental assumptions the developers on the middle end hold
are
>> the primary challenge here. But I think we are going to run into
challenges
>> either way.
>>
>> If the type of these entities is an integer, we will have a non-pointer
>> global, yes. But as Peter points out, this is caught effectively by
asserts
>> in the cast infrastructure and other programming aids. Essentially, the
>> checking of LLVM's type system helps protect the random middle end
>> developer from getting this wrong.
>>
>> On the other hand, if the type of these entities remains consistently
>> pointers, we will still break assumptions that middle end developers
>> routinely make about pointers to globals:
>> - They aren't dereferencable
>> - They aren't aligned
>> - They may be null
>> - The difference between them might not be representable in a
>> pointer-sized-integer
>>
>>
>> Aren’t all these true of “inttoptr’d” integer constants already?  This
is
>> already part of the model for things that are PointerType’s, so I don’t
see
>> how either resolution would change that.
>>
>
> For at least assumptions 1 and 3 this may be true right now for most
> values of type PointerType, but not necessarily for GlobalVariables of type
> PointerType.
>
> Thanks,
> --
> --
> Peter
>


-- 
-- 
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161026/20c06e4c/attachment.html>

On Wed, Oct 26, 2016 at 10:39 PM, Peter Collingbourne <peter at pcc.me.uk>
wrote:
> Re-adding list.
>
> On Wed, Oct 26, 2016 at 10:38 PM, Peter Collingbourne <peter at
pcc.me.uk>
> wrote:
>
>>
>>
>> On Wed, Oct 26, 2016 at 9:43 PM, Chris Lattner <clattner at
apple.com>
>> wrote:
>>
>>> On Oct 26, 2016, at 10:10 AM, Chandler Carruth <chandlerc at
google.com>
>>> wrote:
>>>
>>>
>>> To what Reid said, I'm not really worried about impact on the
middle end
>>> of any of this. We can handle the code changes, etc.
>>>
>>> I agree with Chris about what we're trading off here:
>>>
>>> On Tue, Oct 25, 2016 at 10:48 PM Chris Lattner via llvm-dev <
>>> llvm-dev at lists.llvm.org> wrote:
>>>
>>>> I’d argue the other side of it.  The quality of the code is
higher if
>>>> we have invariants (like all globals are pointers) because that
simplifies
>>>> assumptions by eliminating cases where “is a pointer” appears
to be true,
>>>> but isn’t actually true in all cases.  I’m not an expert on CFI
or how
>>>> widely it will ultimately impact the compiler hacker
consciousness, but I’m
>>>> pretty sure that the current model for globals and functions
will remain
>>>> more prominent.  If you choose to break this invariant, you’ll
be
>>>> continually swimming upstream against assumptions made
throughout the
>>>> compiler, both in code written today but also in code written
in the future.
>>>>
>>>
>>> I agree that mental assumptions the developers on the middle end
hold
>>> are the primary challenge here. But I think we are going to run
into
>>> challenges either way.
>>>
>>> If the type of these entities is an integer, we will have a
non-pointer
>>> global, yes. But as Peter points out, this is caught effectively by
asserts
>>> in the cast infrastructure and other programming aids. Essentially,
the
>>> checking of LLVM's type system helps protect the random middle
end
>>> developer from getting this wrong.
>>>
>>> On the other hand, if the type of these entities remains
consistently
>>> pointers, we will still break assumptions that middle end
developers
>>> routinely make about pointers to globals:
>>> - They aren't dereferencable
>>> - They aren't aligned
>>> - They may be null
>>> - The difference between them might not be representable in a
>>> pointer-sized-integer
>>>
>>>
>>> Aren’t all these true of “inttoptr’d” integer constants already? 
This
>>> is already part of the model for things that are PointerType’s, so
I don’t
>>> see how either resolution would change that.
>>>
>>
>> For at least assumptions 1 and 3 this may be true right now for most
>> values of type PointerType, but not necessarily for GlobalVariables of
type
>> PointerType.
>>
>
I think that before conceding my point I would like to see a response to
this.

Thanks,
-- 
-- 
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161028/c680352f/attachment.html>