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

[Friedman, Eli via llvm-dev]

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
>     semantics
>     > 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
>     feasible
>
>
>
> 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 chips.
>
>         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 safely
>         dereference null pointers, and that no code or data element
>         resides at
>         address zero."  (-fno-delete-null-pointer-checks is the opposite.)
>
>         -Eli
>
>
>  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.

-Eli

-- 
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...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180419/78b28c35/attachment.html>