search for: t25

...n upstream vector ISA to make progress on this. Thank you >From your description it seems like you are seeing an incorrect behavior. If that's the case, it should definitely be fixed. Could you provide the complete DAG before and after the erroneous transformation? -Krzysztof Combining: t25: v2i16 = BUILD_VECTOR t27, t22 Before reduceBuildVecToShuffle SelectionDAG has 14 nodes: t0: ch = EntryToken t2: v4i16,ch = CopyFromReg t0, Register:v4i16 %0 // [a b c d] t26: v2i16 = extract_subvector t2, Constant:i32<0> // [a b] t27: i16 = extract_vector_elt t26, Con...

...lobalAddress:i16<float* @x4> 0, undef:i16 t23: f32,ch = load<Volatile LD4[@x1](tbaa=<0x3dbe418>)> t22, GlobalAddress:i16<float* @x1> 0, undef:i16 t24: f32,ch = load<Volatile LD4[@x2](tbaa=<0x3dbe418>)> t23:1, GlobalAddress:i16<float* @x2> 0, undef:i16 t25: f32,ch = load<Volatile LD4[@x3](tbaa=<0x3dbe418>)> t24:1, GlobalAddress:i16<float* @x3> 0, undef:i16 t26: f32,ch = load<Volatile LD4[@x4](tbaa=<0x3dbe418>)> t25:1, GlobalAddress:i16<float* @x4> 0, undef:i16 t27: i16 = GlobalAddress<float (float, float, fl...

...2 %vreg1 t16: ch = llvm.tpu.dma.write.1KB.async t0, TargetConstant:i32<4602>, t10, t12, t15 t18: i32,ch = CopyFromReg t0, Register:i32 %vreg166 t20: i32 = AssertZext t18, ValueType:ch:i1 t23: i1 = setcc t20, Constant:i32<0>, seteq:ch t25: i32,ch = CopyFromReg t0, Register:i32 %vreg396 t28: i1 = setcc t25, Constant:i32<255>, setugt:ch t29: i1 = and t23, t28 t37: i1 = setcc t29, Constant:i1<-1>, setne:ch t33: ch = brcond t16, t37, BasicBlock:ch<if.end65.1 0x7097330> t35: ch = br t33, Ba...

...a.write.1KB.async t0, TargetConstant:i32<4602>, t10, t12, t15 >> t18: i32,ch = CopyFromReg t0, Register:i32 %vreg166 >> t20: i32 = AssertZext t18, ValueType:ch:i1 >> t23: i1 = setcc t20, Constant:i32<0>, seteq:ch >> t25: i32,ch = CopyFromReg t0, Register:i32 %vreg396 >> t28: i1 = setcc t25, Constant:i32<255>, setugt:ch >> t29: i1 = and t23, t28 >> t37: i1 = setcc t29, Constant:i1<-1>, setne:ch >> t33: ch = brcond t16, t37, BasicBlock:ch<if.end65.1...

...uint %.t15, %.t12 ; <uint> [#uses=2] %.t19 = shr uint %.t16, ubyte 16 ; <uint> [#uses=1] %.t20 = or uint %.t19, %.t16 ; <uint> [#uses=1] %.t22 = mul uint %.t20, 116069625 ; <uint> [#uses=1] %.t25 = shr uint %.t22, ubyte 26 ; <uint> [#uses=1] %.t28 = getelementptr [64 x ubyte]* %table, int 0, uint %.t25 ; <ubyte*> [#uses=1] %.t28 = load ubyte* %.t28 ; <ubyte> [#uses=1] %.t31 = cast ubyte %.t28 to int ; <int>...

...16 > > t23: f32,ch = load<Volatile LD4[@x1](tbaa=<0x3dbe418>)> t22, > GlobalAddress:i16<float* @x1> 0, undef:i16 > >   t24: f32,ch = load<Volatile LD4[@x2](tbaa=<0x3dbe418>)> t23:1, > GlobalAddress:i16<float* @x2> 0, undef:i16 > >   t25: f32,ch = load<Volatile LD4[@x3](tbaa=<0x3dbe418>)> t24:1, > GlobalAddress:i16<float* @x3> 0, undef:i16 > >   t26: f32,ch = load<Volatile LD4[@x4](tbaa=<0x3dbe418>)> t25:1, > GlobalAddress:i16<float* @x4> 0, undef:i16 > >   t27: i16 = Glob...

Hi, Is there a kind of scope mechanism in the instruction lowering pattern language in order to control where instructions are inserted or how they are later reordered during the SelectionDiag linearization? I know the glue chain that stick instructions together. But such mechanism in not provided in instruction lowering pattern. I'm facing many situations where some patterns are lowered into

...:i16 > > t23: f32,ch = load<Volatile LD4[@x1](tbaa=<0x3dbe418>)> t22, > GlobalAddress:i16<float* @x1> 0, undef:i16 > >   t24: f32,ch = load<Volatile LD4[@x2](tbaa=<0x3dbe418>)> t23:1, > GlobalAddress:i16<float* @x2> 0, undef:i16 > >   t25: f32,ch = load<Volatile LD4[@x3](tbaa=<0x3dbe418>)> t24:1, > GlobalAddress:i16<float* @x3> 0, undef:i16 > >   t26: f32,ch = load<Volatile LD4[@x4](tbaa=<0x3dbe418>)> t25:1, > GlobalAddress:i16<float* @x4> 0, undef:i16 > >   t27: i16 = Global...

I see we're missing an isel pattern for add producing carry and doing a memory RMW. I'm going to see if adding that helps anything. ~Craig On Mon, Feb 27, 2017 at 8:47 PM, Nirav Davé via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Yes. I'm seeing that as well. Not clear what's going on. > > In any case it looks to be unrelated to the alias analysis so barring

On Thu, 11 Jan 2007, Schimmel, Mark wrote: > file://docs/LangRef.html#globalvars > > The section describing the definition of global vars discusses that you > can specify an alignment and can also specify a section. Could someone > provide an example that works in gccas in release 1.9 for both defining > which section the var is assigned to and defining the variables >

file://docs/LangRef.html#globalvars The section describing the definition of global vars discusses that you can specify an alignment and can also specify a section. Could someone provide an example that works in gccas in release 1.9 for both defining which section the var is assigned to and defining the variables alignment? Also, is there another document that describes how you define sections

...Thanks in advance for taking your valuable time to help me! Jeff jeff at ubuntu:~/code$ llc dft_gf_msp.ll LLVM ERROR: Cannot select: t28: ch = store<ST2[%le](align=4), trunc to i16> t27, t26, FrameIndex:i32<14>, undef:i32 t26: i32,ch = load<LD2[%sz](align=4), anyext from i16> t25, FrameIndex:i32<2>, undef:i32 t7: i32 = FrameIndex<2> t4: i32 = undef t17: i32 = FrameIndex<14> t4: i32 = undef In function: main LLVMTargetMachine(T, "e-m:e-p:32:32-i8:8:32-i16:16:32-n32-S32", TT, CPU, FS, Options, RM, CM, OL), -------------- next part ---...

...se external snapshots to backup my guests. I use the 'quiesce' option to flush and frees the guest file system with the qemu guest agent. With the exeption of one guest, this procedure works fine. On the 'unwilling' guest, I get this error message: "ERROR 2016-05-25 00:51:19 | T25-bakVMSCmsrvVH2 | fout: internal error: unable to execute QEMU agent command 'guest-fsfreeze-freeze': failed to freeze /: Device or resource busy" I don't think this is not some sort of time-out error, because activation of the fsfreeze and the error message happen immediately afte...

...0:1 t23: ch,glue = SHAVEISD::CALL t21, TargetGlobalAddress:i32<i64 (i64, i64)* @__divdi3> 0, Register:i64 %reg0, Register:i64 %reg1, RegisterMask:Untyped, t21:1 t24: ch,glue = callseq_end t23, TargetConstant:i32<0>, TargetGlobalAddress:i32<i64 (i64, i64)* @__divdi3> 0, t23:1 t25: i64,ch,glue = CopyFromReg t24, Register:i64 %reg0, t24:1 t11: ch = CopyToReg t0, Register:i64 %vreg0, t2 t13: ch = CopyToReg t0, Register:i64 %vreg1, t4 t15: ch = CopyToReg t0, Register:i64 %vreg2, t8 t31: ch = TokenFactor t11, t13, t15, t25:1 LLVM correctly uses a T...

...32-i32:32:32-i64:64-n32:32-S128", since my back end basically extends with vector instructions the LLVM BPF back end. So, at instruction selection it lowers the <128 x i16> value to <128 x i64>, since pointers have 64 bits, which we can see from the debug info of llc: t25: v128i16 = BUILD_VECTOR Constant:i64<31>, Constant:i64<31>, Constant:i64<31>, Constant:i64<31>, Constant:i64<31>, Constant:i64<31>, Constant:i64<31>, Constant:i64<31>, Constant:i64<31>, Constant:i64<31>, Constant:i64<31>, ......

...= add FrameIndex:i64<1>, Constant:i64<64> t42: v4i32,ch = load<LD16[%0+64](align=8)(dereferenceable)> t20, t41, undef:i64 t46: i64 = add FrameIndex:i64<1>, Constant:i64<80> t47: v4i32,ch = load<LD16[%0+80](align=8)(dereferenceable)> t20, t46, undef:i64 t25: ch = store<ST16[%1]> t20, t24, FrameIndex:i64<0>, undef:i64 t29: i64 = add FrameIndex:i64<0>, Constant:i64<16> t30: ch = store<ST16[%1+16]> t20, t28, t29, undef:i64 t33: i64 = add FrameIndex:i64<0>, Constant:i64<32> t34: ch = store<S...

Is there an established way of disabling a DAG combine on a per target basis, where it appears to be detrimental to the generated code? Writing if (!mytarget) in DAGCombiner.cpp works but tends to be erased by git merge and generally doesn't look ideal. Writing the inverse transform in target specific code doesn't work in this instance and in general creates an infinite loop. Guidance

Hello. I wanted to inform that I fixed the bug from the previous email. The main reason for the bug was that I thought that the SDNode masked_gather is returning only 1 value, but it returns 2 (hence, I guess, the earlier reported, difficult to follow, error: "Assertion `New->getNumTypes() == 1"). masked_gather returns 2 values because: // SDTypeProfile -

...f, i32 undef > %c = shufflevector <8 x float> %c01, <8 x float> %c2.w, <12 x i32> <i32 0, i32 1, i32 2, i32 undef, i32 4, i32 5, i32 6, i32 undef, i32 8, i32 9, i32 10, i32 undef > ; t26: v12f32 = CONCAT_VECTORS t23, t24, t25 ret <12 x float> %c ;----------- ; t27: v4f32 = EXTRACT_SUBVECTOR t26, 0 ; t28: v4f32 = EXTRACT_SUBVECTOR t26, 4 ; t29: v4f32 = EXTRACT_SUBVECTOR t26, 8 ; t42: ch,glue = CopyToReg t0, Register:v4f32 $q0, t27 ; t44: ch,glue = CopyToReg t42, Register:v4f32 $q1, t28, t42:1 ; t4...

Hello list. I'm trying to rebuild the 2.6.9.67.0.20.EL kernel, but it fails even without modifications. How did I try it? Created a (non-root) build environment (not a mock ) Installed the kernel.scr.rpm and did a rpmbuild -ba --target=`uname -m` kernel-2.6.spec 2> prep-err.log | tee prep-out.log The build failed at the end: Processing files: kernel-xenU-devel-2.6.9-67.0.20.EL Checking