search for: splats

Hi, During the discussion on introducing scalable vectors we established that we could use the canonical IR form for splats of scalable vector types (insert element into lane 0 of an undef vector, shuffle that with another undef vector of the same type and a zeroinitializer mask). We do run into a problem for lowering to SelectionDAG however, since the canonical form there is a BUILD_VECTOR with all elements being the...

...s. > > Amara > > > On Aug 29, 2019, at 5:26 AM, Graham Hunter via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Hi, > > > > During the discussion on introducing scalable vectors we established > that we could use the canonical IR form for splats of scalable vector types > (insert element into lane 0 of an undef vector, shuffle that with another > undef vector of the same type and a zeroinitializer mask). > > > > We do run into a problem for lowering to SelectionDAG however, since the > canonical form there is a BUILD_V...

Hi All, First of all, I am not native English speaker. While reading BUILD_VECTOR related code, for example, PPCTargetLowering::LowerBUILD_VECTOR, I see "splat" here and there. Could someone explain what it is (does splat mean the same thing across the whole code base)? Besides, from my English dictionary, I don't know why we call such thing as "splat"... :p Regards,

Hi, I noticed that ConstantFP::get automatically returns the appropriately types Constant depending on the LLVM type passed in (i.e. if called with a vector, it returns a splat vector with the given constant). Is there any simple way to do the inverse of this function? i.e., given a llvm::Value, check whether it is either a scalar of the given constant value or a splat vector with the given

----- Original Message ----- > Hi, > > I noticed that ConstantFP::get automatically returns the > appropriately > types Constant depending on the LLVM type passed in (i.e. if called > with a vector, it returns a splat vector with the given constant). > > Is there any simple way to do the inverse of this function? i.e., > given a llvm::Value, check whether it is either

Thanks, Sanjay, that makes sense. The opportunity for improving instcombining splat sounds promising. Another question about shuffle simplification. This is a testcase from test/Transforms/InstCombine/vec_shuffle.ll: define <4 x i32> @test10(<4 x i32> %tmp5) nounwind { %tmp6 = shufflevector <4 x i32> %tmp5, <4 x i32> undef, <4 x i32> <i32 1, i32 undef, i32

Wow. Somehow, I forgot about vbroadcast and vpbroadcast. =[ Sorry about that. I'll fix those. On Fri, Sep 26, 2014 at 3:39 AM, Andrea Di Biagio <andrea.dibiagio at gmail.com > wrote: > Hi Chandler, > > Here is another test. > > When looking at the AVX codegen, I noticed that, when using the new > shuffle lowering, we no longer emit a single vbroadcastss in the case

Hi! as highlevel languages (like opencl) support operations with a vector on one side and a scalar on the other side (e.g. vector * scalar) it would be convenient if llvm ir would have a splat instruction that takes a scalar and produces a vector with all elements filled with the scalar. i assume that i'm not the first one who has this idea so what was the reason not to include such an

Hi, We have a function in IRBuilder.h Value *CreateVectorSplat(unsigned NumElts, Value *V, const Twine &Name = "") { .. } This function creates 2 instructions - "insertelement" and "shuffle" with all-zero mask. Now I want to add Value *getSplatValue(Value *Val). This function will try to recognize the pattern - insertelement+shuffle and return the splat value

...h never > had and never will. Somewhere along the lines I think you got > confused. Entirely possible, that frequently happens! :) > But hey, you're the boss. Will rip the patch out at earliest > opportunity and live with the consequences, even if testing for > constant splats ends up in a shufflevector class (see #4 above.) To be clear, I'm entirely in favor of improving support for *both* buildvector and shuffle. Most of my comments have been about shuffle, but improvements to introduce a new buildvectorsdnode class would also make sense... but they should...

This snippet of IR is interesting: %sub.ptr.div.iS37_D = sdiv <2 x i64> %sub.ptr.sub.iS36_D, <i64 24, i64 24> %cmp10S38_D = icmp ugt <2 x i64> %sub.ptr.div.iS37_D, %splatInsMapS1_D.splat %zextS39_D = sext <2 x i1> %cmp10S38_D to <2 x i64> %BCS39_D = bitcast <2 x i64> %zextS39_D to i128 %mskS39_D = icmp ne i128 %BCS39_D, 0 br i1 %mskS39_D,

https://bugs.freedesktop.org/show_bug.cgi?id=67277 Priority: medium Bug ID: 67277 Assignee: nouveau at lists.freedesktop.org Summary: Lockdep splat on kernel 3.10.0 QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: Linux (All) Reporter: peter at hurleysoftware.com

On Tue, Sep 23, 2014 at 2:35 PM, Simon Pilgrim <llvm-dev at redking.me.uk> wrote: > If you don’t want to spend time on this, I’d be happy to create a > candidate patch for review? I’ve been unclear if you were taking patches > for your shuffle work prior to it becoming the default. While I'm happy to work on it, I'm even more happy to have patches. =D -------------- next

------------------------------------ IR ------------------------------------------------------------------ if.then.i.i.i.i.i.i: ; preds = %if.then4 %S25_D = zext <2 x i32> %splatLDS17_D.splat to <2 x i64> %umul_with_overflow.i.iS26_D = shl <2 x i64> %S25_D, <i64 3, i64 3> %extumul_with_overflow.i.iS26_D = extractelement <2 x i64>

...18 11:38:19, Mark Rutland wrote: > On Mon, Feb 26, 2018 at 11:52:56AM +0100, Jan Kara wrote: > > On Fri 23-02-18 15:47:36, Mark Rutland wrote: > > > Hi all, > > > > > > While fuzzing arm64/v4.16-rc2 with syzkaller, I simultaneously hit a > > > number of splats in the block layer: > > > > > > * inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-R} usage in > > > jbd2_trans_will_send_data_barrier > > > > > > * BUG: sleeping function called from invalid context at mm/mempool.c:320 > > > > > > *...

On Mon, Feb 26, 2018 at 11:52:56AM +0100, Jan Kara wrote: > On Fri 23-02-18 15:47:36, Mark Rutland wrote: > > Hi all, > > > > While fuzzing arm64/v4.16-rc2 with syzkaller, I simultaneously hit a > > number of splats in the block layer: > > > > * inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-R} usage in > > jbd2_trans_will_send_data_barrier > > > > * BUG: sleeping function called from invalid context at mm/mempool.c:320 > > > > * WARNING: CPU: 0 PID: 0 at block/blk...

On 07/24/2015 03:42 AM, Benjamin Kramer wrote: >> On 24.07.2015, at 08:06, zhi chen <zchenhn at gmail.com> wrote: >> >> It seems that that it's hard to vectorize int64 in LLVM. For example, LLVM 3.4 generates very complicated code for the following IR. I am running on a Haswell processor. Is it because there is no alternative AVX/2 instructions for int64? The same thing

On Mon, Feb 26, 2018 at 11:52:56AM +0100, Jan Kara wrote: > On Fri 23-02-18 15:47:36, Mark Rutland wrote: > > Hi all, > > > > While fuzzing arm64/v4.16-rc2 with syzkaller, I simultaneously hit a > > number of splats in the block layer: > > > > * inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-R} usage in > > jbd2_trans_will_send_data_barrier > > > > * BUG: sleeping function called from invalid context at mm/mempool.c:320 > > > > * WARNING: CPU: 0 PID: 0 at block/blk...

...ors around with a constant mask, which itself is a constant vector.) I'm not seeing how a splat is equivalent to a shuffle (unless the second input operand is totally undef and the mask has a magic pattern, which I think confuses more than clarifies.) On a pure vector machine, like the CellSPU, splats and shuffles are not equivalent concepts (*) The important part of #3 is that we really want an array of ints (using -1 > for undef) for the shuffle mask, not "operands". This eliminates the > nastiness we have now were we need a buildvector, and it eliminates the > dance we ha...

...number of easily synthesized > patterns are required for autovectorization. The `zeroinitializer` constant > can be used in the same manner as fixed-length vectors for a constant zero > splat. This can then be combined with `insertelement` and `shufflevector` > to create arbitrary value splats in the same manner as fixed-length vectors. > > For constants consisting of a sequence of values, an experimental `stepvector` > intrinsic has been added to represent a simple constant of the form > `<0, 1, 2... num_elems-1>`. To change the starting value a splat of the new >...