search for: getpointerbasewithconstantoffset

...-O3 -vectorize on it, does not create any vector instructions. I also played a little with the vectorizer options, but was not able to get this example vectorized. Is this because the chain is too short? >>> One problem with the current implementation is that it relies on >>> GetPointerBaseWithConstantOffset to determine if two loads or stores >>> share the same base address. This fails with partially-unrolled loops >>> because it cannot "undo" all of the additions to the offset induction >>> variable in order to understand that some of the loads and stores are >...

...oller > > chose the unrolling factor to preserve the maximum available alignment, > > but I don't think that it currently does so. > I don't know, but it sounds like a good thing to do. > > > One problem with the current implementation is that it relies on > > GetPointerBaseWithConstantOffset to determine if two loads or stores > > share the same base address. This fails with partially-unrolled loops > > because it cannot "undo" all of the additions to the offset induction > > variable in order to understand that some of the loads and stores are > > rea...

...= add i64 %indvars.iv, 4 %arrayidx78.4 = getelementptr inbounds [200 x [200 x double]]* @a, i64 0, i64 %indvars.iv10, i64 %indvars.iv.next.3 ... I think that it would be better if it calculated the base pointer at the beginning and then added to it somehow. Is that possible? For one thing, llvm::GetPointerBaseWithConstantOffset cannot currently tell that all of the loads and stores reference the same base pointer with a constant offset. If it could, that would facilitate vectorization (and possibly other optimizations as well). If the current scheme is the only way (given LLVM's abstraction model), would it make sens...

...would be nice if the loop unroller > chose the unrolling factor to preserve the maximum available alignment, > but I don't think that it currently does so. I don't know, but it sounds like a good thing to do. > One problem with the current implementation is that it relies on > GetPointerBaseWithConstantOffset to determine if two loads or stores > share the same base address. This fails with partially-unrolled loops > because it cannot "undo" all of the additions to the offset induction > variable in order to understand that some of the loads and stores are > really adjacent in memo...

..., so it > should give an expression of the form (base + offset) on the pointer > of the load. Specifically, you can use ScalarEvolution to subtract the expression for the base descriptor from the expression for the loaded pointer and see if the result is a SCEVConstant. Also, you might find GetPointerBaseWithConstantOffset (in ValueTracking.h) useful.  -Hal > > Cheers > siddharth > > On Wed 30 May, 2018, 16:30 Venkataramanan Kumar via llvm-dev, > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Hi,  > > Below is the snippet of  LLVM IR cod...

...This behavior can be suppressed using the -bb-vectorize-aligned-only flag. It would be nice if the loop unroller chose the unrolling factor to preserve the maximum available alignment, but I don't think that it currently does so. One problem with the current implementation is that it relies on GetPointerBaseWithConstantOffset to determine if two loads or stores share the same base address. This fails with partially-unrolled loops because it cannot "undo" all of the additions to the offset induction variable in order to understand that some of the loads and stores are really adjacent in memory. This is somethin...

...t create > any vector instructions. I also played a little with the vectorizer > options, but was not able to get this example vectorized. Is this > because the chain is too short? > > >>> One problem with the current implementation is that it relies on > >>> GetPointerBaseWithConstantOffset to determine if two loads or stores > >>> share the same base address. This fails with partially-unrolled loops > >>> because it cannot "undo" all of the additions to the offset induction > >>> variable in order to understand that some of the loads and...

...oller > > chose the unrolling factor to preserve the maximum available alignment, > > but I don't think that it currently does so. > I don't know, but it sounds like a good thing to do. > > > One problem with the current implementation is that it relies on > > GetPointerBaseWithConstantOffset to determine if two loads or stores > > share the same base address. This fails with partially-unrolled loops > > because it cannot "undo" all of the additions to the offset induction > > variable in order to understand that some of the loads and stores are > > rea...

You can run SCEV which will see through bitcasts and GEPs, so it should give an expression of the form (base + offset) on the pointer of the load. Cheers siddharth On Wed 30 May, 2018, 16:30 Venkataramanan Kumar via llvm-dev, < llvm-dev at lists.llvm.org> wrote: > Hi, > > Below is the snippet of LLVM IR code generated by Flang > > ---snip-- > %3 = getelementptr i64,

Hi, Below is the snippet of LLVM IR code generated by Flang ---snip-- %3 = getelementptr i64, i64* %"a$sd", i64 11, !dbg !16 %4 = bitcast i64* %3 to i32*, !dbg !16 %5 = load i32, i32* %4, align 4, !dbg !16, !tbaa !22 ---snip-- My requirement is for any such LoadInst (example: %5), I want to check if its base GEP (i.e. %3) loads at particular offset (11) from its corresponding

On 11/08/2011 11:45 AM, Hal Finkel wrote: > I've attached the latest version of my autovectorization patch. > > Working through the test suite has proved to be a productive > experience ;) -- And almost all of the bugs that it revealed have now > been fixed. There are still two programs that don't compile with > vectorization turned on, and I'm working on those now,

I've attached the latest version of my autovectorization patch. Working through the test suite has proved to be a productive experience ;) -- And almost all of the bugs that it revealed have now been fixed. There are still two programs that don't compile with vectorization turned on, and I'm working on those now, but in case anyone feels like playing with vectorization, this patch