similar to: RFC: Implementing -fno-delete-null-pointer-checks in clang

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

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

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

Fair warning, the following is a devil's advocate position, but it's also a serious question. Given the entire point of this flag appears to be bug mitigation, why not frame this as a sanitizer?  If we had a hypothetical -fsanitize=dereference which tried to catch dereferenced pointers derived from null, wouldn't that handle the case at hand? i.e. Why are we focused on *hiding*

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

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

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

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

On Thu, Apr 19, 2018 at 2:53 PM Tim Northover <t.p.northover at gmail.com> wrote: > On 19 April 2018 at 22:36, Manoj Gupta via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > 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. >

Personally I don't think adding a new address space to express the idea that loads and stores may successfully dereference address zero is the best design. The existing code to support the handling of address spaces does not inspire a lot of confidence. I am a simple non-GPU compiler developer. I have no idea how address spaces are supposed to work. When I read code that deals with them, I

On Thu, Apr 19, 2018 at 3:56 PM, Manoj Gupta via llvm-dev <llvm-dev at lists.llvm.org> wrote: > My understanding is we only want to disable the optimizations regarding > undefined behavior > related to null pointer deference optimizations. And address space checks > will end up > disabling more optimizations than needed. [Repeating what others have already mentioned on this

> 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

On 19 April 2018 at 22:36, Manoj Gupta via llvm-dev <llvm-dev at lists.llvm.org> wrote: > 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. Isn't that exactly what we want? Did you look in enough detail to determine that these optimizations *should* have

On 30 April 2018 at 11:14, John McCall via llvm-dev <llvm-dev at lists.llvm.org > wrote: > > On Apr 28, 2018, at 4:12 PM, Sanjoy Das via cfe-dev < > cfe-dev at lists.llvm.org> wrote: > > On Thu, Apr 19, 2018 at 3:56 PM, Manoj Gupta via llvm-dev > > <llvm-dev at lists.llvm.org> wrote: > >> My understanding is we only want to disable the

> On Apr 28, 2018, at 4:12 PM, Sanjoy Das via cfe-dev <cfe-dev at lists.llvm.org> wrote: > On Thu, Apr 19, 2018 at 3:56 PM, Manoj Gupta via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> My understanding is we only want to disable the optimizations regarding >> undefined behavior >> related to null pointer deference optimizations. And address space checks

> In addition, It is already not easy to convince Linux Kernel maintainers to > accept clang specific patches. > Worse performance when compared to GCC may make it even harder to push more > patches. > (There are already many complains about clang not supporting optimizations > that Linux kernel is used to. > As a side note: x86 maintainers deliberately broke clang support in

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

On Mon, May 14, 2018 at 12:07 PM Friedman, Eli <efriedma at codeaurora.org> wrote: > On 5/12/2018 9:23 PM, Philip Reames via llvm-dev wrote: > > Fair warning, the following is a devil's advocate position, but it's > > also a serious question. > > > > Given the entire point of this flag appears to be bug mitigation, why > > not frame this as a

On 5/12/2018 9:23 PM, Philip Reames via llvm-dev wrote: > Fair warning, the following is a devil's advocate position, but it's > also a serious question. > > Given the entire point of this flag appears to be bug mitigation, why > not frame this as a sanitizer?  If we had a hypothetical > -fsanitize=dereference which tried to catch dereferenced pointers > derived

On 4/20/18, James Y Knight wrote: > > > Yep. "-fnull-pointer-is-valid" has been suggested before. > -fplacate-linux-kernel-developers ? Csaba -- You can get very substantial performance improvements by not doing the right thing. - Scott Meyers, An Effective C++11/14 Sampler So if you're looking for a completely portable, 100% standards-conformat way to get the wrong