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

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>

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
>>     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.
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.

-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/f45b1f06/attachment.html>

On 19 April 2018 at 19:57, Friedman, Eli via cfe-dev
<cfe-dev at lists.llvm.org> wrote:
> 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.
Probably a fair point, though I think it has a subtle effect on how
the feature is documented. It becomes more about whether code in this
translation unit is permitted to access an object at 0 than whether
such an object exists.

Cheers.

Tim.

On Thu, Apr 19, 2018 at 11:59 AM Friedman, Eli <efriedma at
codeaurora.org>
wrote:
> 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>
> 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?
>
>
> 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.
>
> -Eli
>
Thanks Eli,

I was looking around for the cases where AddrSpace !=0 are checked. Seems
like there are a bunch of optimizations that will fail to apply for non
zero address spaces.
So I'll start with the function attribute approach.

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