[llvm-dev] [cfe-dev] RFC: Implementing -fno-delete-null-pointer-checks in clang

[David Zarzycki via llvm-dev]

> On Apr 30, 2018, at 15:05, John McCall via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
>> On Apr 30, 2018, at 2:58 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote:
>> On Mon, Apr 30, 2018 at 11:14 AM, John McCall <rjmccall at apple.com> wrote:
>>> The LLVM address space design has pushed well beyond the sensible boundaries
>>> of less-is-more and really needs some concerted effort to actually define the expected
>>> properties of different address spaces instead of a dozen different engineers applying
>>> a "don't do this optimization if the pointer is in a non-zero address space" rule to the
>>> optimizer with a shotgun.
>>> 
>>> In fact, if we'd already done that, we wouldn't need any sort of address-space hack
>>> to support this request.  We'd just need a very simple audit of the places that check
>>> the "are dereferences of the zero address undefined behavior" bit to make sure that
>>> they honor it even in address space 0.  But instead that audit will be confused by a
>>> thousand places that just bail out for non-zero address spaces without further
>>> explanation.
>> 
>> I agree.  The pattern of bailing out if AddrSpace != 0 is unfortunate.
>> 
>> We also need to cap the amount of extra semantics that can be put on address
>> spaces.  For instance, we should probably never support trapping semantics on
>> loads/stores, even via address spaces.
> 
> I would say instead that address spaces are not the right way to support trapping
> semantics on loads/stores.

Hi John,

I might be misunderstanding the thread here, but are there architectures other than Intel that support alternative address spaces? I’m asking because x86_64 dropped support for having the code, data, stack, and “extra” segments be different from each other; and the only two remaining segment registers, “FS” and “GS”, are only used in practice to alias the current address space. In fact, *user-space* instructions were later added to read/write the FS/GS segment bases, thus embracing the fact that these segment registers are used in practice to alias the current address space.[1]

I don’t think LLVM needs to model FS/GS as anything other than aliases into the existing address space.

Dave

[1] – Note, these new user-space instructions require permission from the kernel to execute, and popular kernels haven’t enabled them. Last I knew, the Linux folks seem receptive to the idea of enabling these instructions, but the conversation keeps stalling on implementation details.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180430/754b3d2d/attachment.html>