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

Richard Smith via cfe-dev cfe-dev at lists.llvm.org
Mon Apr 30 13:35:04 PDT 2018

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

More information about the cfe-dev mailing list