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

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
>
> --
> 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/20180418/70c28e33/attachment.html>

On Wed, Apr 18, 2018 at 12:54 PM Tim Northover <t.p.northover at
gmail.com>
wrote:


On Wed, Apr 18, 2018 at 12:02 PM Friedman, Eli <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> 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?

e.g.
1. Add to already overloaded pointer types? e.g.
p[n]:<size>:<abi>:<pref>:<idx>: *<NullPointerValid ?
1 : 0>*
2. (My preference) Or create another unique field identifier: e.g.
np[n]: <NullPointerValid
? 1 : 0>

Thanks,
Manoj
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180419/016326de/attachment.html>

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>