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

Displaying 20 results from an estimated 7000 matches similar to: "[cfe-dev] RFC: Implementing -fno-delete-null-pointer-checks in clang"

2018 Apr 19
0
[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
2018 Apr 19
3
[cfe-dev] RFC: Implementing -fno-delete-null-pointer-checks in clang
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
2018 Apr 18
3
[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
2018 Apr 18
0
[cfe-dev] RFC: Implementing -fno-delete-null-pointer-checks in clang
> 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
2018 Apr 19
0
[cfe-dev] RFC: Implementing -fno-delete-null-pointer-checks in clang
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
2018 Apr 19
2
[cfe-dev] RFC: Implementing -fno-delete-null-pointer-checks in clang
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
2018 Apr 18
0
[cfe-dev] 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
2018 Apr 20
3
[cfe-dev] RFC: Implementing -fno-delete-null-pointer-checks in clang
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
2018 Apr 18
5
RFC: Implementing -fno-delete-null-pointer-checks in clang
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
2018 Apr 19
0
[cfe-dev] RFC: Implementing -fno-delete-null-pointer-checks in clang
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
2018 Apr 18
2
A struct {i8, i64} has size == 12, clang says size 16
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
2018 Apr 19
0
A struct {i8, i64} has size == 12, clang says size 16
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
2018 Apr 19
2
How to set Target/Triple of ExecutionEngine
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.    
2018 Apr 19
0
How to set Target/Triple of ExecutionEngine
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
2012 Sep 07
2
[LLVMdev] The LLVMLinux Project
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
2018 Apr 19
5
[cfe-dev] RFC: Implementing -fno-delete-null-pointer-checks in clang
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. >
2018 Apr 20
0
[cfe-dev] RFC: Implementing -fno-delete-null-pointer-checks in clang
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
2018 Apr 26
0
[cfe-dev] RFC: Implementing -fno-delete-null-pointer-checks in clang
> 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
2018 Apr 30
0
[cfe-dev] RFC: Implementing -fno-delete-null-pointer-checks in clang
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
2018 May 14
0
RFC: Implementing -fno-delete-null-pointer-checks in clang
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