search for: anyext

Hi, A bit more information. I believe my problem lies with the fact that the load is left as 'anyext from i8'. On the XCore target we know this will become an 8bit zext load - as there is no 8bit sign extended load! If BB#1 were to force the load to a "zext from i8" would this information be available in BB#2? BB#1: 0x268c1b0: i32 = Register %vreg1 [ID=3] 0x2689d80: i32,ch =...

Hi, Within a basic block I can remove unnecessary register copies + zero sign extensions of unsigned-8bit-loaded values by implementing isZExtFree() for ISD::LOAD nodes. ...But not between basic blocks. The first block does a CopyFromReg of the unsigned-8bit-loaded vreg1 into a new vreg2. The second block then does a unnecessary zext to vreg2. What I want is the 2nd block to use the original

Duncan, I had a few thoughts regarding our short discussion yesterday. I am not sure how we can lower SEXT into the vpmovsx family of instructions. I propose the following strategy for the ZEXT and ANYEXT family of functions. At first, we let the Type Legalizer/VectorOpLegalizer scalarize the code. Next, we allow the dag-combiner to convert the BUILD_VECTOR node into a shuffle. This is possible because all of the inputs of the build vector come from two values(src and (undef or zero)). Finally, th...

Hi, I am receiving an LLVM Error from a custom 16-bit backend I am creating. I am having trouble understanding the error/problem and how to go about solving it. The error is: LLVM ERROR: Cannot select: t29: i32,ch = load<LD2[%x.addr], anyext from i16> t14, FrameIndex:i16<0>, undef:i16 t7: i16 = FrameIndex<0> t9: i16 = undef In function: mul_add Can anyone provide any pointers as to what the problem is and potential places I should look to fix it? Thanks and best regards, Mush -------------- next part ------------...

I have the following selection DAG: SelectionDAG has 9 nodes: t0: ch = EntryToken t2: i64,ch = CopyFromReg t0, Register:i64 %vreg0 t16: i32,ch = load<LD1[%ptr](tbaa=<0x10023c9f448>), anyext from i8> t0, t2, undef:i64 t15: v16i8 = BUILD_VECTOR t16, t16, t16, t16, t16, t16, t16, t16, t16, t16, t16, t16, t16, t16, t16, t16 t11: ch,glue = CopyToReg t0, Register:v16i8 %V2, t15 t12: ch = PPCISD::RET_FLAG t11, Register:v16i8 %V2, t11:1 and the following pattern that I'd like...

...flow bit) dst_high32 = dst_high32 + src1_high32 dst_high32 = dst_high32 + src2_high32 I tried it with patterns like the following in InstrInfo.td (this is obviously wrong, but you have to start somewhere): def : Pattern<(set LLRegs:$dst, (add LLRegs:$src1, LLRegs:$src2)), [(set LLRegs:$dst, (anyext (add (trunc LLRegs:$src1), (trunc LLRegs:$src2))))]>; ... but tablegen complains: "Cannot use 'add' in an output pattern!". Is this the right way to do it - that is, defining a pattern for an operation? ... Or better: What is the right way to do it? Any help appreciated! T...

...erns, I stumbled upon this braindead testcase: %0 = load <8 x i8>* %src, align 1 %1 = zext <8 x i8> %0 to <8 x i16> turning into: pmovzxbw (%rsi), %xmm0 pand <0xff,0xff,...>, %xmm0, %xmm0 v8i8 isn't legal, so the load became an anyext load from v8i8 to v8i16, with the pand masking out the unwanted/zero bits. In that example, if you declare zextloads from v8i8 legal, and add the simple corresponding pattern, the pand isn't generated anymore, as expected. So, unless I'm missing something, shouldn't we declare them le...

...on Ada code. Can anyone help me on the following error message? Thanks, ZY LLVM ERROR: Cannot select: 0xa7a0bf0: f32 = truncate 0xa7a5ea8 [ID=24] 0xa7a5ea8: i32 = X86ISD::SHLD 0xa790280, 0xa790390, 0xa76e088 [ID=22] 0xa790280: i32,ch = load 0xa7386a0, 0xa7a68d8, 0xa7a5628<LD1[%1482+4], anyext from i8> [ID=19] 0xa7a68d8: i32 = add 0xa7a6040, 0xa7a11c8 [ID=15] 0xa7a6040: i32,ch = CopyFromReg 0xa7386a0, 0xa790c98 [ORD=741] [ID=12] 0xa790c98: i32 = Register %vreg7 [ORD=741] [ID=3] 0xa7a11c8: i32 = Constant<13> [ID=7] 0xa7a5628: i32 = undef [ORD...

Hi Nadav, > I had a few thoughts regarding our short discussion yesterday. > > I am not sure how we can lower SEXT into the vpmovsx family of instructions. I propose the following strategy for the ZEXT and ANYEXT family of functions. what I would like to understand first is why there are any vector xEXT nodes at all! As I tried to explain on IRC, I don't think you ever get these from the GCC autovectorizer except as part of a shuffle-extend pair. Where do you get these nodes from? Does the intel aut...

...1, 0, "INSERT_SUBREG", 0, 0, NULL, NULL, OperandInfo107 }, // Inst #5 = INSERT_SUBREG THe sixth field is zero, which means it doesn't have the the MayLoad flag set. x86-64 does have a few variants of INSERT_SUBREG, and one of them does have a load: def : Pat<(i64 (anyext (loadi32 addr:$src))), (INSERT_SUBREG (i64 (IMPLICIT_DEF)), (MOV32rm addr:$src), x86_subreg_32bit)>; This isn't currently being reflected in the InstrInfo tables. Naively, it seems like we should add a separate INSERT_SUBREGrm...

..., >> ZY >> >> >> LLVM ERROR: Cannot select: 0xa7a0bf0: f32 = truncate 0xa7a5ea8 [ID=24] >> 0xa7a5ea8: i32 = X86ISD::SHLD 0xa790280, 0xa790390, 0xa76e088 [ID=22] >> 0xa790280: i32,ch = load 0xa7386a0, 0xa7a68d8, >> 0xa7a5628<LD1[%1482+4], >> anyext from i8> [ID=19] >> 0xa7a68d8: i32 = add 0xa7a6040, 0xa7a11c8 [ID=15] >> 0xa7a6040: i32,ch = CopyFromReg 0xa7386a0, 0xa790c98 [ORD=741] >> [ID=12] >> 0xa790c98: i32 = Register %vreg7 [ORD=741] [ID=3] >> 0xa7a11c8: i32 = Constant&l...

...his? Ciao, Duncan. > > Thanks, > ZY > > > LLVM ERROR: Cannot select: 0xa7a0bf0: f32 = truncate 0xa7a5ea8 [ID=24] > 0xa7a5ea8: i32 = X86ISD::SHLD 0xa790280, 0xa790390, 0xa76e088 [ID=22] > 0xa790280: i32,ch = load 0xa7386a0, 0xa7a68d8, 0xa7a5628<LD1[%1482+4], > anyext from i8> [ID=19] > 0xa7a68d8: i32 = add 0xa7a6040, 0xa7a11c8 [ID=15] > 0xa7a6040: i32,ch = CopyFromReg 0xa7386a0, 0xa790c98 [ORD=741] [ID=12] > 0xa790c98: i32 = Register %vreg7 [ORD=741] [ID=3] > 0xa7a11c8: i32 = Constant<13> [ID=7] >...

Hi Dan, If you set the node's action to "Custom", you should be able to interfere in the type legalisation phase (before it gets promoted to a 64-bit MUL) by overriding the "ReplaceNodeResults" function. You could either expand it to a different libcall directly there, or replace it with a target-specific node (say XXXISD::MUL32) which claims to take i64 types but you

...the correct code. The instructions in question are: %tmp1 = load float* %test ; <float> [#uses=1] %conv = fpext float %tmp1 to double ; <double> [#uses=1] Which emits the following dag: f64,ch = load 01809908, 018092A8, 01809110 <0035A544:0> <anyext f32> alignment=4 If the load and the fpext were emitted seperatly, I could handle them with my fpext and load patterns in tablegen. However, since they are being combined into a single DAG, I have not been able to figure out how to get them to generate the correct code. I can match against t...

...:MUL32 (gdb) p N->dumpr() 0x23ad0d0: i32 = add [ID=0] 0x23aff60, 0x23acfd0 0x23aff60: i64 = <<Unknown Node #192>> [ID=-3] 0x23b0260, 0x23b0160 0x23b0260: i64 = and [ID=-3] 0x23af660, 0x23b0060: i64 = Constant<4294967295> [ID=-3] 0x23af660: i64,ch = load<LD4[@i], anyext from i32> [ID=-3] 0x238b068: ch = EntryToken [ID=-3], 0x23ac7d0: i64 = GlobalAddr\ ess<i32* @i> 0 [ID=-3], 0x23ac9d0: i64 = undef [ID=-3] 0x23b0160: i64 = and [ID=-3] 0x23afc60, 0x23b0060: i64 = Constant<4294967295> [ID=-3] 0x23afc60: i64,ch = load<LD4[@j], anyext from i...

...; ZY > > > LLVM ERROR: Cannot select: 0xa7a0bf0: f32 = truncate 0xa7a5ea8 [ID=24] > 0xa7a5ea8: i32 = X86ISD::SHLD 0xa790280, 0xa790390, 0xa76e088 [ID=22] > 0xa790280: i32,ch = load 0xa7386a0, 0xa7a68d8, 0xa7a5628<LD1[%1482+4], > anyext from i8> [ID=19] > 0xa7a68d8: i32 = add 0xa7a6040, 0xa7a11c8 [ID=15] > 0xa7a6040: i32,ch = CopyFromReg 0xa7386a0, 0xa790c98 [ORD=741] > [ID=12] > 0xa790c98: i32 = Register %vreg7 [ORD=741] [ID=3] > 0xa...

...M ERROR: Cannot select: 0xa7a0bf0: f32 = truncate 0xa7a5ea8 >> [ID=24] >> 0xa7a5ea8: i32 = X86ISD::SHLD 0xa790280, 0xa790390, 0xa76e088 >> [ID=22] >> 0xa790280: i32,ch = load 0xa7386a0, 0xa7a68d8, >> 0xa7a5628<LD1[%1482+4], >> anyext from i8> [ID=19] >> 0xa7a68d8: i32 = add 0xa7a6040, 0xa7a11c8 [ID=15] >> 0xa7a6040: i32,ch = CopyFromReg 0xa7386a0, 0xa790c98 >> [ORD=741] >> [ID=12] >> 0xa790c98: i32 = Register %vreg7 [ORD=741] [ID=3] &...

...: llvmdev at cs.uiuc.edu Subject: Re: SelectionDAG scalarizes vector operations. Hi Nadav, > I had a few thoughts regarding our short discussion yesterday. > > I am not sure how we can lower SEXT into the vpmovsx family of instructions. I propose the following strategy for the ZEXT and ANYEXT family of functions. what I would like to understand first is why there are any vector xEXT nodes at all! As I tried to explain on IRC, I don't think you ever get these from the GCC autovectorizer except as part of a shuffle-extend pair. Where do you get these nodes from? Does the intel aut...

[snip] > The ABI boundary lowering requires types to be broken down further into > 'legal types' that can be mapped to registers. The secondary breakdown is > currently handled by TargetLowering::LowerCallTo() calling > getRegisterType() and getNumRegisters(). Most ABIs are defined in terms > of C types, not LLVM IR types, so there is a close connection between the C >

...7a0bf0: f32 = truncate 0xa7a5ea8 > [ID=24] > 0xa7a5ea8: i32 = X86ISD::SHLD 0xa790280, 0xa790390, > 0xa76e088 [ID=22] > 0xa790280: i32,ch = load 0xa7386a0, 0xa7a68d8, > 0xa7a5628<LD1[%1482+4], > anyext from i8> [ID=19] > 0xa7a68d8: i32 = add 0xa7a6040, 0xa7a11c8 [ID=15] > 0xa7a6040: i32,ch = CopyFromReg 0xa7386a0, 0xa790c98 > [ORD=741] > [ID=12] > 0xa790c98: i32 = Register %...