[cfe-dev] [llvm-dev] RFC: Implementing -fno-delete-null-pointer-checks in clang
Friedman, Eli via cfe-dev
cfe-dev at lists.llvm.org
Thu Apr 19 11:59:53 PDT 2018
On 4/19/2018 11:57 AM, Friedman, Eli via cfe-dev wrote:
> On 4/19/2018 11:48 AM, Manoj Gupta via llvm-dev wrote:
>> On Wed, Apr 18, 2018 at 12:54 PM Tim Northover
>> <t.p.northover at gmail.com <mailto:t.p.northover at gmail.com>> wrote:
>> On Wed, Apr 18, 2018 at 12:02 PM Friedman, Eli
>> <efriedma at codeaurora.org <mailto:efriedma at codeaurora.org>> wrote:
>> > Despite the name, the flag actually has rather straightforward
>> > from the compiler's perspective. From the gcc docs for
>> > -fdelete-null-pointer-checks: "Assume that programs cannot safely
>> > dereference null pointers, and that no code or data element
>> resides at
>> > address zero." (-fno-delete-null-pointer-checks is the opposite.)
>> Ah, now that's quite a bit more palatable. I really should have read
>> the docs before spouting "my favourite rant #1". Then my main concern
>> is that we end up with a sufficiently clear (and documented)
>> definition that we're not promising more than we intend. I get very
>> grumpy if I can't tell someone with UB that they're Doing It Wrong.
>> Of the two options, I still think the second is a non-starter.
>> Something between the two might be a datalayout flag specifying
>> addrspace(0) behaviour. It's pretty easy to argue that it'd be
>> good if
>> code used some kind of
>> "DataLayout::isPointerIntrinsicallyInvalid(Value *)" for this kind of
>> thing anyway (rename or relocate at will).
>> And the name really is terrible, we should change it if at all
>> On Wed, Apr 18, 2018 at 1:46 PM Jon Chesterfield via llvm-dev
>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>> I'm working with an embedded architecture that could, in some
>> situations, run faster if code or data could be located at
>> address zero. I don't know whether this applies to other embedded
>> Despite the name, the flag actually has rather
>> straightforward semantics
>> from the compiler's perspective. From the gcc docs for
>> -fdelete-null-pointer-checks: "Assume that programs cannot
>> dereference null pointers, and that no code or data element
>> resides at
>> address zero." (-fno-delete-null-pointer-checks is the
>> Thanks Tim and Eli,
>> I should have put the GCC description for the flag in the email.
>> Regarding the suggestion to DataLayout, It is an interesting idea. I
>> like it in particular since it will avoid creating a new llvm
>> optimization flag and is auto embedded in IR.
>> Given that, how do we want to proceed, do we want to add yet another
>> field to the DataLayout string?
> Modifying the datalayout is not a good idea; it doesn't interact with
> LTO correctly, and the frontend and the backend generally need to
> agree on the datalayout.
> You could maybe use a module flag, if the address-space thing doesn't
> work for some reason, but we don't like to introduce more of those if
> we can avoid it.
Actually, thinking about it a bit more, a function attribute would be
better than a module flag. But I'd still like to explore the
address-space thing first, since we already have the LLVM infrastructure
to make that work.
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-dev