[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>
> 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
> 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
> 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
> spaces. For instance, we should probably never support trapping semantics
> loads/stores, even via address spaces.
> I would say instead that address spaces are not the right way to support
> 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.
> I don’t think LLVM needs to model FS/GS as anything other than aliases
> into the existing address space.
>  – 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-dev