similar to: GEP with a null pointer base

> On Jul 6, 2017, at 3:07 PM, Chris Lattner <clattner at nondot.org> wrote: > > >> On Jul 6, 2017, at 2:05 PM, Peter Lawrence via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> >>> On Jul 6, 2017, at 1:00 PM, via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>

Hi everyone, I've got a problem that I would like some input on. The problem basically boils down to a program that I am compiling, whose source I don't control, doing something like this: p = (char*)0 + n where 'n' is an intptr_t-sized value that the program knows is actually a valid address for a pointer. clang translates this as %p = getelementptr inbounds i8, i8*

> glibc does accept patches...or are you talking about two separate instances of this problem, both in glibc and something else? I originally saw this in a benchmark (which it may be possible to get changed) and only afterward found the glibc idiom. The most recent glibc code is a bit more complicated than I represented below. If you look up obstack.h you can see what’s there now.

Can we go back a little? 1) Add a new transformation to InstCombine that will replace 'getelementptr > i8, i8* null, <ty> %n' with 'inttoptr <ty> %n to i8*' when <ty> has the > same size as a pointer for the target architecture. What's the actual problem with this approach? I personally find it the most compelling - it is well-defined (well,

> On Thu, Aug 10, 2017 at 12:22 AM, Nema, Ashutosh via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> I’m not sure how transforming GEP offset to i8 type will help alias >> analysis & SROA for the mentioned test case. > > It should neither help nor hinder AA or SROA -- the two GEPs (the complex one and the simple one) are equivalent. > Since memory isn't

I’m not entirely opposed to solution #3. As I said, my concern is that there are cases it would miss. For instance, if I had some code like this: char *get_ptr(char *base, intptr_t offset) { return base + offset; } char *convert_to_ptr(intptr_t ptr_val) { return get_ptr((char*)0, ptr_val); } There the idiom would only appear after inlining, so the front end couldn’t handle it. The

Hi, I have a doubt with GEP transformation in the instruction-combiner. Consider below test-case: struct ABC { int A; int B[100]; struct XYZ { int X; int Y[100]; } OBJ; }; void Setup(struct ABC *); int foo(int offset) { struct ABC *Ptr = malloc(sizeof(struct ABC)); Setup(Ptr); return Ptr->OBJ.X + Ptr->OBJ.Y[33]; } Generated IR for the test-case: define i32 @foo(i32

Hello all, LangRef says it is undefined behavior to pass null to a nonnull argument (`call f(nonnull null);`), but the semantics is too strong for a few existing optimizations. To support these, we can relax the semantics so `f(nonnull null)` is equivalent to `f(poison)`, but (A) it again blocks another set of optimizations, and (B) this makes the semantics of nonnull deviate from other

Paul, The proposition under discussion is this Deleting UB, rather than warning about UB, should not be the default, as this is contrary to the essentially universal software engineering practice of writing software that is compiler warning free, static analyzer warning free, and dynamic analyzer warning free. This is based on the assumption that in order for llvm to be useful to its

David, Here is the definition accepted by Hal of what we’re doing > 1. Sometimes there are abstraction penalties in C++ code > 2. That can be optimized away after template instantiation, function inlining, etc > 3. When they for example exhibit this pattern > if (A) { > stuff; > } else { > other stuff including “undefined behavior”; > } > 4. Where the

Hi Johannes, >> Not sure the semantics of "used" you propose is sufficient. AFAIU the >> proposal, "used" could only be used in cases where the function will >> always trigger UB if poison is passed as argument. The semantics of >> attributes is usually the other way around, since function calls need >> to have UB as strong as the worst

> Saying “The C++ language lets me assume that that won’t happen, & > optimize on that basis” is an assumption that that’s what the user > wants, but you haven’t asked you’ve just assumed, and AFAICT it is an > incorrect assumption. Well, by using C++, the programmer agrees that the rules of the language apply to their program, and the rules of the language say that the compiler

Chandler, The only thing David made clear that wasn’t already clear is that he believes UB to be “comparatively rare”, which is in agreement with what Hal already said which is that he does not expect deleting UB will be of benefit to for example SPEC benchmarks. Given that it is “comparatively rare”, why all the effort to delete it ? And why make deleting it the default rather

> > > Message: 5 > Date: Tue, 25 Jul 2017 00:12:35 -0700 > From: Sean Silva via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> > To: Peter Lawrence <peterl95124 at sbcglobal.net <mailto:peterl95124 at sbcglobal.net>> > Cc: llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>, John Regehr >

Hello Chandler, > ``` > void f(int *arr1, int *arr2, int length) { > intptr_t rel_offset = arr2 - arr1; > int *arr1_end = arr1 + length; > for (int *p = arr1; p < arr1_end; p += sizeof(int)) { > do_something(p, p + rel_offset); > } > } > ``` > > For example, a common loop optimization technique is something like the following in *pseudocode* (note

Sean, Let me re-phrase a couple words to make it perfectly clear > On Jul 21, 2017, at 6:29 PM, Peter Lawrence <peterl95124 at sbcglobal.net> wrote: > > Sean, > > Dan Gohman’s “transform” changes a loop induction variable, but does not change the CFG, > > Hal’s “transform” deletes blocks out of the CFG, fundamentally altering it. > > These are two totally

Not sure the semantics of "used" you propose is sufficient. AFAIU the proposal, "used" could only be used in cases where the function will always trigger UB if poison is passed as argument. The semantics of attributes is usually the other way around, since function calls need to have UB as strong as the worst behavior of the function. If a function may for some reason trigger

Mehdi, Hal’s transformation only kicks in in the *presence* of UB, and it does not matter how that UB got there, whether by function inlining or without function inlining. The problem with Hal’s argument is that the compiler does not have a built in ouija board with which it can conjure up the spirit of the author of the source code and find out if the UB was intentional with the

Hi Johannes, > From the Lang-Ref statement > > "With the inbounds keyword, the result value of the GEP is undefined > if the address is outside the actual underlying allocated object and > not the address one-past-the-end." > > I'd argue that the actual offset value (here 0) is irrelevant. The GEP > value is undefined if inbounds is present and the

Hi Johannes, >> So, the thinking here is: LLVM cannot exclude the possibility of an >> object of size 0 existing at any given address. The pointer returned >> by "GEPi p 0" then would be one-past-the-end of such a 0-sized object. >> Thus, "GEPi p 0" is the identitiy function for any p, it will not >> return poison. > > I don't see the