similar to: TBAA for subset of a loaded value

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

In short, the problem with !tbaa.struct is that in most cases it cannot be converted to !tbaa. For transformations like SROA this means they cannot propagate !tbaa.struct tags for aggregate-accessing instructions like memcpy() calls to the resulting loads and stores. On 31/10/17 05:11, Hal Finkel wrote: > > On 10/18/2017 05:49 AM, Ivan Kosarev via llvm-dev wrote: >> Hello,

Hello, The motivation behind this proposal is to make it possible to propagate TBAA information through scalarizing transformations, such as SROA, that rewrite accesses to aggregates, e.g., memcpy() calls, into accesses to scalars, that is, load and store instructions. Currently, we decorate instructions that initialize and copy aggregates with !tbaa.struct tags that generally cannot be

To clarify further, what this paper proposes is to use !tbaa for all kinds of accesses, including aggregate ones, so we don't need to bother trying to convert them when an aggregate access becomes a series of scalar accesses or vice versa. As I said, in most cases such conversions are not possible anyway, because !tbaa.struct tags do not refer to the type of the aggregate itself and only

Hi all, I have a question regarding dynamic indexing into a vector with GEP. I see that in the ScalarReplAggregates pass in the LLVM 3.2 release the call SROA::isSafeGEP() will now allow alloca scalarization in the case where a GEP index into a vector isn’t a constant. My question is: what is the expected behavior when the index is out of bounds of the vector? Is it undefined? I have an

On 02/11/17 05:54, Hal Finkel wrote: > > On 10/31/2017 05:02 AM, Ivan Kosarev wrote: >> To clarify further, what this paper proposes is to use !tbaa for all >> kinds of accesses, including aggregate ones, so we don't need to >> bother trying to convert them when an aggregate access becomes a >> series of scalar accesses or vice versa. As I said, in most cases

[+Arnold] > On Jun 10, 2015, at 1:29 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > [+CC Andy] > >> Can anyone familiar with ScalarRevolution tell me whether this is an >> expected behavior or a bug? > > Assuming you're talking about 2*k, this is a bug. ScalarEvolution > should be able to prove that {0,+,4} is <nsw> and

On 08/20/2017 11:22 AM, Daniel Berlin via llvm-dev wrote: > Sorry, hit send early. > > > On Sun, Aug 20, 2017 at 9:16 AM, Daniel Berlin <dberlin at dberlin.org > <mailto:dberlin at dberlin.org>> wrote: > > > > On Sun, Aug 20, 2017 at 8:54 AM, Ivan A. Kosarev via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at

Hello all, There is a missing vectorization opportunity issue with clang 4.0 with the file attached. Indeed, when compiled with -O2, the "op_distance" function get vectorized, but not the "op" one. For information, this test case has been reduced from a file generated by the Pythran compiler (https://github.com/serge-sans-paille/pythran). If we take a look at the generated

Hello to whom this may concern, Versioned this as I saw identical title before. I'm compiling a clang project where I'm seeing GVN mess up and replace a load with a wrong def value. I am using LLVM-3.5, but the problem has been observed upto 3.8. To illustrate the problem, define i32 @main scalar.ph: <initialize [80 x i16] %dest> ... preheader: %index=0 br test, loop1, bb2

before inlining all 20005 after inlining somewhere here changed made it NoAlias after Global Variable Optimizer 20014 20373 20255 20372 20254 before GVN 19993 20011 19991 20010 20030 It appears that TBAA metadata certainly changed after inlining and subsequent passes. I have attached the .bc file. I think I will try to dump out more TBAA metadata between passes. The method in

Thanks for quick reply Daniel, I tried to make a simple C testcase, but could not reproduce the same condition with output from Clang. I suppose I could modify the C code to make it look similar with TBAA's; I may be able to provide this by eod. > store %ptr above the load. My mistake; I was referring to the store $lcssa in bb2. Looking at the C source code, it should definitely alias

> > > > I do not believe the current proposal will solve all of those cases, > particularly when the fields are the same type and structures are > compatible but they cannot overlap in C/C++ anyway. > > One of the threads is titled "[PATCH] D20665: Claim NoAlias if two GEPs index different fields of the same struct" For example, given struct { int arr_a[2];

Do you have a formal description of your approach with examples? I have a bit of trouble visualizing exactly what your approach does. On Mon, Aug 14, 2017 at 9:58 AM, Ivan A. Kosarev via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hello Steven, Hal and Daniel, > > Thanks a lot for your discussion; it really helps with summarizing current > TBAA issues and ways to resolve

=== PROBLEM === (See this bug https://llvm.org/bugs/show_bug.cgi?id=26445) IR contains code for loading a float from float * and storing it to a float * address. After canonicalization of load in InstCombine [1], new bitcasts are added to the IR (see bottom of the email for code samples). This prevents select speculation in SROA to work. Also after SROA we have bitcasts from int32 to float.

> 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

Hi Mark, It is not clear to me at all that preventing the merging is the right solution. There are a large number of analysis, including alias analysis, and optimizations that use GetUnderlyingObject, and related routines to search back through GEPs. They only do this up to some small finite depth (six, IIRC). So reducing the GEP depth is likely the right solution for InstCombine (which has the

Suppose I have compiled a record equivalent to: struct ST { short s; char c3, c4; } STvar; and llvm IR: %STvar = alloca { i16, i8, i8 } According to "The Often Misunderstood GEP Instruction", I can construct an artificial llvm type to supply to GEP. (The "ugly GEP"?) So I can think of three ways to access STvar.c3. These are in order of increasing easiness for me to

On Wed, Mar 16, 2016 at 8:34 AM, Mehdi Amini via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > How do it interact with the "typeless pointers" work? > Right - the goal of the typeless pointer work is to fix all these bugs related to "didn't look through bitcasts" in optimizations. Sometimes that's going to mean more work (because the code

Hal Finkel <hfinkel at anl.gov> wrote on 16.03.2015 17:56:20: > If you want to do it at a clang level, the right thing to do is to > fixup the ABI lowerings for pointers to keep them pointers in this case. > So this is an artifact of the way that we pass structures, and > constructing a general solution at the ABI level might be tricky. > I've cc'd Uli, who did most