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

[Manoj Gupta via llvm-dev]

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>