search for: visitshufflevectorinst

...hat it should return a vector of type <2 x float>. %14 is a direct dump of the value returned from the statement "new ShuffleVectorInst(...)", and it says it returned a vector of type <3 x float>. This is later confirmed by an assertion in the DAG code (I believe in a function visitShuffleVectorInst), complaining an incorrect number of elements for some type. My question is whether I misunderstood the documentation, or that there is a bug in the code generation. Apparently I didn't misread the documentation, but I find it hard to believe that the code generation is buggy. Any suggestion w...

...did not attempt to combine these shuffles, and unfortunately no later pass did so either. This seems to be an issue which is due to keeping instcombine simple and fast, as well as a conservativeness to not produce any new shuffles not already in the input program (see comment in InstCombiner::visitShuffleVectorInst). For some reason a bit unclear to me the backend will get into trouble then. Should improved optimization of shufflevector instructions handle all of them globally, or just the new ones produced by the vectorizers? At least in the code produced by the vectorizers, it seems fair to combine the...

Hi! Is there a pass that optimizes vector operations? If I have for examle a sequence of shufflevector instructions that optimizes them? (in opencl notation e.g. a.xyzw.wzyx.xxxx -> a.wwww) -Jochen

Instcombine does of this, late codegen also does some of it. -Chris On May 14, 2010, at 5:58 AM, Jochen Wilhelmy <j.wilhelmy at arcor.de> wrote: > Hi! > > Is there a pass that optimizes vector operations? > If I have for examle a sequence of shufflevector instructions > that optimizes them? > (in opencl notation e.g. a.xyzw.wzyx.xxxx -> a.wwww) > > -Jochen

On Feb 2, 2010, at 4:56 AM, Maarten Hoeben wrote: > > Hi, > > When I emit the llvm::ShuffleVectorInst instruction from my code generator > the result vector has the length of vector 1, instead of the element type of > vector 1 and the length of the mask vector; > > %13 = load <3 x float>* %w ; <<3 x float>> [#uses=0] > %14 =

Hi, When I emit the llvm::ShuffleVectorInst instruction from my code generator the result vector has the length of vector 1, instead of the element type of vector 1 and the length of the mask vector; %13 = load <3 x float>* %w ; <<3 x float>> [#uses=0] %14 = shufflevector <3 x float> %13, <3 x float> undef, <2 x i32> <i32 1, i32

Ok, makes sense. My suggestion is that we patch the IR Verifier to ensure that the mask is indeed a vector of constants and/or undefs. Right now it only runs the standard checks for instructions. We will also run Alive2 on the test suite to make sure undef is never replaced in practice. Thanks, Nuno -----Original Message----- From: Eli Friedman <efriedma at quicinc.com> Sent: 27 de