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

On 4/18/2018 11:21 AM, Tim Northover via cfe-dev wrote:
> On 18 April 2018 at 18:13, Manoj Gupta via cfe-dev
> <cfe-dev at lists.llvm.org> wrote:
>> Therefore, I would like to implement support for this flag (maybe with
a
>> different name),
> I'd suggest -mdo-what-i-mean; the whole idea is horribly
> underspecified, and basically rips up the LangRef in favour of a
> nebulous set of good and bad optimizations (probably as dictated by
> the ones that have bitten someone who wrote bad code recently and was
> grumpy enough about it to complain at us).
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

> 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

Tim.

On 04/18/2018 02:54 PM, Tim Northover via llvm-dev
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.
But then we're back to auditing everything (FWIW, I'm not sure
there's
going to be a great alternative to an audit). What behavior would you
like under LTO? We could use a different address space by default
(although, unless you also change the address space used for allocas,
you're going to end up with addressspace casts all over the place).

 -Hal
>  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
>
> Tim.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

On Wed, Apr 18, 2018 at 3:54 PM Tim Northover via llvm-dev <
llvm-dev at lists.llvm.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

+1 for implementing the feature.

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

Whether or not this is put into DataLayout, moving all the null-related
addrSpace != 0 checks into an accessor seems like a great idea. Besides
this feature request, presumably there's also other uses of non-zero
address spaces for which the pointer 0 could usefully be treated as
invalid...

And the name really is terrible, we should change it if at all feasible


Yep. "-fnull-pointer-is-valid" has been suggested before.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180420/5f98a8d2/attachment.html>