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

[Richard Smith via llvm-dev]

On 30 April 2018 at 13:26, David Zarzycki via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

>
>
> 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?
>

Yes, they're also used by GPU targets IIUC.


> 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.
>
> _______________________________________________
> 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/20180430/36641add/attachment-0001.html>