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

[John McCall via cfe-dev]

> On Apr 30, 2018, at 4:26 PM, David Zarzycki <dave at znu.io> wrote:
>> On Apr 30, 2018, at 15:05, John McCall via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>>> On Apr 30, 2018, at 2:58 PM, Sanjoy Das <sanjoy at playingwithpointers.com <mailto:sanjoy at playingwithpointers.com>> wrote:
>>> On Mon, Apr 30, 2018 at 11:14 AM, John McCall <rjmccall at apple.com <mailto: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?

Yes.  They're commonplace in GPUs and also used in some distributed system architectures.  Also, any x32-like ABI can support a short/long pointer distinction.

John.

> 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/cfe-dev/attachments/20180430/34f09fc9/attachment.html>