[cfe-dev] [llvm-dev] RFC: Implementing -fno-delete-null-pointer-checks in clang
Friedman, Eli via cfe-dev
cfe-dev at lists.llvm.org
Thu Apr 19 11:57:33 PDT 2018
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
> > 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
> 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
> 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.)
> 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.
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...
More information about the cfe-dev