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

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

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

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

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

Hi, This is regarding support for -fno-delete-null-pointer-checks in clang (PR 9251). Linux kernel uses this flag to keep null pointer checks from getting optimized away. Since clang does not currently support this flag, it often invites comments from kernel devs that clang is not yet *ready* to compile Linux kernel. I have also heard that developers working on firmware, bare-metal tools and

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

I think I see a potential issue. My ExecutionEngine setup may not be using the same target as my object code emitting, and in this test case I'm running in the ExecutionEngine.  I'll go over this code to ensure I'm creating the same triple and see if that helps -- I'm assuming it will, since I can't imagine the exact same triple with clang would produce a different layout. On

What exactly is your alignment settings in your LLVM struct? Something like this would tell you the alignment of "something". const llvm::DataLayout dl(theModule); size_t size = dl.getPrefTypeAlignment(something); IIn "my" compiler, I don't do anything special to align structs, so it's plausibly your specific data-layout that says that i64 only needs aligning to

I don't know if I'm setting the triple of my execution engine correctly.  This is leading to an issue where a struct `{i8,i64}` is not getting the same layout as the ABI expects. I setup my engine/module like this:      llvm::SmallVector<std::string,2> mattrs;      llvm::EngineBuilder builder{ unique_ptr<llvm::Module>(module) };      llvm::ExecutionEngine * ee = builder.    

Taking one step back, I'm not clear I'm even setting the triple/DataLayout on the module correctly:     module = new llvm::Module( "test", *llvm_context );     module->setTargetTriple( platform::target->triple ); Is that enough to create an appropriate DataLayout for the module?  I don't see anyway to convert a triple to a DataLayout, so I can't call

I'd like to announce the LLVMLinux project. This project aims to fully build the Linux kernel using Clang/LLVM on the various architectures supported by the Linux kernel. The project consolidates the work of the lll-project, the PAX team, and Mark Charlebois' work on the ARM kernel. http://llvm.linuxfoundation.org <http://llvm.linuxfoundation.org/> The hope is that this project

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

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

> 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 Mon, Apr 30, 2018 at 11:14 AM, John McCall <rjmccall at apple.com> wrote: > The LLVM address space design has pushed well beyond the sensible boundaries > of less-is-more and really needs some concerted effort to actually define the expected > properties of different address spaces instead of a dozen different engineers applying > a "don't do this optimization if the

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