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

[Peter Collingbourne via llvm-dev]

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>