[llvm-dev] RFC: Absolute or "fixed address" symbols as immediate operands

[Peter Collingbourne via llvm-dev]

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>