similar to: [LLVMdev] module passes that eliminate unused global symbols

On 15 November 2013 20:05, Frank Winter <fwinter at jlab.org> wrote: > Good catch! That was the problem in my case too. I totally > overlooked the alignment requirement for AVX. I wonder if the validation mechanism shouldn't have caught it earlier... Do you guys run validate on the modules before JIT-ing? --renato -------------- next part -------------- An HTML attachment was

On 1 July 2015 at 21:22, Frank Winter <fwinter at jlab.org> wrote: > there were two follow-up emails. I only got one... weird... > The issue is solved. The SLP vectorizer has > a magic number built into the code which determines the max. vector length > to search for. That was set to 128 bits. Increasing it to 256 bits solved > the issue. That looks like a simple fix. Is

On 30 October 2013 18:40, Frank Winter <fwinter at jlab.org> wrote: > const std::uint64_t ir0 = (i+0)%4; // not working > I thought this would be the case when I saw the original expression. Maybe we need to teach module arithmetic to SCEV? --renato -------------- next part -------------- An HTML attachment was scrubbed... URL:

Good that you bring this up. I still have no solution to this vectorization problem. However, I can rewrite the code and insert a second loop which eliminates the 'urem' and 'div' instructions in the index calculations. In this case, the inner loop's trip count would be equal to the SIMD length and the loop vectorizer ignores the loop. Unrolling the loop and SLP is not an

Frank, It sounds like the SLP vectorizer thinks that it is more profitable to use 128bit wide operations (because 256bit operations are double pumped on Sandybridge). Did you see a different result on Haswell? Thanks, Nadav > On Jul 1, 2015, at 11:06 AM, Frank Winter <fwinter at jlab.org> wrote: > > I realized that the function parameters had no alignment attributes on them.

Hmm.. I don't quite understand. How can a module validator catch this, when it's the pointers, i.e. the payload, you pass as function arguments that need to be aligned.. ?! Frank On 15/11/13 15:16, Renato Golin wrote: > On 15 November 2013 20:05, Frank Winter <fwinter at jlab.org > <mailto:fwinter at jlab.org>> wrote: > > Good catch! That was the problem in my

Hi Frank, This loop should be vectorized by the SLP-vectorizer. It has several scalars (C[0], C[1] … ) that can be merged into a vector. The SLP vectorizer can’t figure out that the stores are consecutive because SCEV can’t analyze the OR in the index calculation: %2 = and i64 %i.04, 3 %3 = lshr i64 %i.04, 2 %4 = shl i64 %3, 3 %5 = or i64 %4, %2 %11 = getelementptr inbounds float*

It's not reproducible with 'opt'. I call the SLP pass from my application and only then the wrong IR gets generated. On the attached module I call via the function pass manager: 1) TargetLibraryInfo with the target triple 2) Set the data layout 3) Basic Alias Analysis 4) SLP vectorizer This produces the wrong IR. On the other hand running the attached module through 'opt

On 12 November 2013 15:14, Frank Winter <fwinter at jlab.org> wrote: > I am asking because the option 'force-vector-width' is too restrictive. > I would like to leave open the possibility to use vector width 2. I was about to say that, and you saved us both one cycle. ;) What you could do is to force an architecture that doesn't have AVX, only SSE. I'm not sure how

On 12 November 2013 15:53, Frank Winter <fwinter at jlab.org> wrote: > .. forcing the vector size to 4 does not prevent using AVX. > Sure. That's more for tests than anything else. So, there are ways of disabling stuf in Clang, for instance "-mattr=-avx" or "-target-feature -avx", but I'm not sure how you're doing it in the JIT. I'm also not sure

> On Aug 7, 2014, at 2:57 PM, Arnold Schwaighofer <aschwaighofer at apple.com> wrote: > > Your .ll file does not have a data layout. Opt will not initialize the DataLayoutPass. The SLP vectorizer will not vectorize because there is no DataLayoutPass. > > debug-cmake/bin/opt -default-data-layout="e-m:e-i64:64-f80:128-n8:16:32:64-S128" -basicaa -slp-vectorizer -S

I added your suggestion and am using this now llvm::legacy::FunctionPassManager *functionPassManager = new llvm::legacy::FunctionPassManager(Mod); llvm::PassRegistry &registry = *llvm::PassRegistry::getPassRegistry(); initializeScalarOpts(registry); functionPassManager->add( new llvm::TargetLibraryInfoWrapperPass(llvm::TargetLibraryInfoImpl(targetMachine->getTargetTriple())) );

Sent from my iPhone > On Nov 5, 2013, at 7:39 PM, Frank Winter <fwinter at jlab.org> wrote: > > Good that you bring this up. I still have no solution to this vectorization problem. > > However, I can rewrite the code and insert a second loop which eliminates the 'urem' and 'div' instructions in the index calculations. In this case, the inner loop's trip

Related to this subject is the __attribute__(aligned(X)) that can be set on a type in C/C++. It is being used when generating the load / stores / memcpy / ... but is lost with respect to the type's attribute. In many a case this could help various analysis or transforms to provide more accurate results when such a type is used. The __builtin_assume_aligned could be an way to solve this.

A quite small but yet complete example function which all vectorization passes fail to optimize: #include <cstdint> #include <iostream> void bar(std::uint64_t start, std::uint64_t end, float * __restrict__ c, float * __restrict__ a, float * __restrict__ b) { for ( std::uint64_t i = start ; i < end ; i += 4 ) { { const std::uint64_t ir0 = (i+0)%4 + 8*((i+0)/4);

I am trying my luck on this global reduction kernel: float foo( int start , int end , float * A ) { float sum[4] = {0.,0.,0.,0.}; for (int i = start ; i < end ; ++i ) { for (int q = 0 ; q < 4 ; ++q ) sum[q] += A[i*4+q]; } return sum[0]+sum[1]+sum[2]+sum[3]; } LV: Checking a loop in "foo" LV: Found a loop: for.cond1 LV: Found an induction variable. LV: We

There certainly is support; after all AMD supports both OpenCL and HIP (a dialect of C++ very close to cuda). AMD device libraries (in bitcode form) are installed when ROCm ( https://rocm.github.io/ ) is installed. AMD device libraries are mostly written in (OpenCL) C and open source at https://github.com/RadeonOpenCompute/ROCm-Device-Libs . They are configured by linking in a number tiny

Hi Frank, Thanks for working on this. Please look at vectorizeStoreChains. In this function we process all of the stores in the function in buckets of 16 elements because constructing consecutive stores is implemented using an O(n^2) algorithm. You can try to increase this threshold to 128 and see if it helps. I also agree with Renato and Chad that adding a flag to tell the SLP-vectorizer to

TargetMachine::CGFT_AssemblyFile is exactly what I am trying to write out. Frank On 02/22/2016 11:06 AM, Rafael Espíndola wrote: > On 19 February 2016 at 16:16, Frank Winter via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> TargetMachine::addPassesToEmitFile(..) >> requires as its 2nd argument an raw_pwrite_stream. >> >> Is it possible to create such a

----- Original Message ----- > > Hi Nadav, > > that's the whole point of it. I can't in general make the index > calculation simpler. The example given is the simplest non-trivial > index function that is needed. It might well be that it's that > simple that the index calculation in this case can be thrown aways > altogether and - as you say - be replaced by