search for: assertzext

...d by the time it reaches instruction selection. > > So for this particular issue with shifts, introducing a target-specific WasI32 > > node and converting to (shl val, (WasI32 shamt)) in a target DAG combine looks > > plausible. > > You can represent "WasI32" using AssertZext i5. That seems like a > reasonable approach. I hadn't considered AssertZext, thanks for the suggestion. Don't we really want AssertAnyExt i5 though (which doesn't currently exist)? We can't guarantee that the bits other than lower 5 are zero. I'd be willing to believe that...

...te). > > It seems like I should be able to insert a custom hook using the > register class to identify the type, potentially in ISelDAGToDag.cpp or is > there a better place for this to be done? > > Thanks. > > > It sounds to me like you are looking for the AssertSext / AssertZext nodes > > -Matt > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150127/5e0b18d4/attachment.html>

...t12: i32,ch = CopyFromReg t0, Register:i32 %vreg79 t15: i32,ch = CopyFromReg t0, Register:i32 %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>, setn...

...Register:i32 %vreg79 >> t15: i32,ch = CopyFromReg t0, Register:i32 %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...

...[ORD=1] [ID=1] >> >> 0x2384a70:<multiple use> >> 0x2384570: i32,ch = load 0x2536968, 0x2384b70, >> 0x2384a70<LD4[FixedStack-1]> [ORD=1] [ID=10] >> >> 0x2384470: ch = ValueType:i8 [ORD=1] [ID=4] >> >> 0x2384970: i32 = AssertZext 0x2384570, 0x2384470 [ORD=1] [ID=12] >> >> 0x2536968:<multiple use> >> 0x2384670: i32 = FrameIndex<-2> [ORD=2] [ID=3] >> >> 0x2384a70:<multiple use> >> 0x2384c70: i32,ch = load 0x2536968, 0x2384670, >> 0x2384a70&...

On Sep 29, 2010, at 12:36 AM, Heikki Kultala wrote: > On 29 Sep 2010, at 06:25, Heikki Kultala wrote: > >> Our architecture has 1-bit boolean predicate registers. >> >> I've defined comparison >> >> def NErrb : InstTCE<(outs I1Regs:$op3), (ins I32Regs:$op1,I32Regs:$op2), "", [(set I1Regs:$op3, (setne I32Regs:$op1, I32Regs:$op2))]>;

...68: <multiple use> 0x248db80: i32 = FrameIndex<-1> [ORD=1] [ID=1] 0x248da80: <multiple use> 0x248d580: i32,ch = load 0x263e968, 0x248db80, 0x248da80<LD4[FixedStack-1]> [ORD=1] [ID=10] 0x248d480: ch = ValueType:i8 [ORD=1] [ID=4] 0x248d980: i32 = AssertZext 0x248d580, 0x248d480 [ORD=1] [ID=12] 0x263e968: <multiple use> 0x248d680: i32 = FrameIndex<-2> [ORD=2] [ID=3] 0x248da80: <multiple use> 0x248dc80: i32,ch = load 0x263e968, 0x248d680, 0x248da80<LD4[FixedStack-2]> [ORD=2] [ID=11] 0x248d380: c...

I have a CopyToReg that is copying from different size types, what's the best way to change that to a zext or sext node based on signed or unsigned? I'm fairly unfamiliar with SelectionDAG process (outside of the docs on llvm website). It seems like I should be able to insert a custom hook using the register class to identify the type, potentially in ISelDAGToDag.cpp or is there a better

...pe(0); // The only "good" option for this node is to custom lower it. switch (TLI.getOperationAction(Node->getOpcode(), VT)) { @@ -710,6 +710,7 @@ Result = LegalizeOp(Node->getOperand(0)); break; } + } break; case ISD::AssertSext: case ISD::AssertZext:

On 29 Sep 2010, at 06:25, Heikki Kultala wrote: > Our architecture has 1-bit boolean predicate registers. > > I've defined comparison > > > def NErrb : InstTCE<(outs I1Regs:$op3), (ins I32Regs:$op1,I32Regs:$op2), "", [(set I1Regs:$op3, (setne I32Regs:$op1, I32Regs:$op2))]>; > > > > > But then I end up having the following bug: > >

...6 = icmp ne i32 %vecext4, %vecext5 %cmp7 = xor i1 %1, %cmp6 ... and the SelectionDAG before TypeLegalizer is like this. t0: ch = EntryToken t2: i32,ch = CopyFromReg t0, Register:i32 %vreg0 t3: ch = ValueType:i32 t5: i32,ch = CopyFromReg t2:1, Register:i32 %vreg1 t7: i32 = AssertZext t5, ValueType:ch:i1 t8: v2i32 = BUILD_VECTOR t2, t7 t11: v2i32 = BUILD_VECTOR Constant:i32<0>, Constant:i32<-23> t15: i32,ch = CopyFromReg t0, Register:i32 %vreg2 t22: i32 = add t15, Constant:i32<1> t24: ch = CopyToReg t0, Register:i32 %vreg3, t22...

As previously discussed in an RFC <http://lists.llvm.org/pipermail/llvm-dev/2018-October/126690.html>, the RISC-V backend has i64 as the only legal integer type for the RV64 target. Thanks to variable-sized register class support, this means there is no need for duplication of either patterns or instruction definitions for RV32 and RV64. It's worth noting that RV64I is a different base

...7 = xor i1 %1, %cmp6 > > ... > > and the SelectionDAG before TypeLegalizer is like this. > > t0: ch = EntryToken > t2: i32,ch = CopyFromReg t0, Register:i32 %vreg0 > t3: ch = ValueType:i32 > t5: i32,ch = CopyFromReg t2:1, Register:i32 %vreg1 > t7: i32 = AssertZext t5, ValueType:ch:i1 > t8: v2i32 = BUILD_VECTOR t2, t7 > t11: v2i32 = BUILD_VECTOR Constant:i32<0>, Constant:i32<-23> > t15: i32,ch = CopyFromReg t0, Register:i32 %vreg2 > t22: i32 = add t15, Constant:i32<1> > t24: ch = CopyToReg t0, Register:...

...84b70: i32 = FrameIndex<-1> [ORD=1] [ID=1] > > 0x2384a70: <multiple use> > 0x2384570: i32,ch = load 0x2536968, 0x2384b70, > 0x2384a70<LD4[FixedStack-1]> [ORD=1] [ID=10] > > 0x2384470: ch = ValueType:i8 [ORD=1] [ID=4] > > 0x2384970: i32 = AssertZext 0x2384570, 0x2384470 [ORD=1] [ID=12] > > 0x2536968: <multiple use> > 0x2384670: i32 = FrameIndex<-2> [ORD=2] [ID=3] > > 0x2384a70: <multiple use> > 0x2384c70: i32,ch = load 0x2536968, 0x2384670, > 0x2384a70<LD4[FixedStack-2]> [OR...

Hi Andrew, Thank you for the suggestion. I've looked at CodeGenPrepare.cpp and MoveExtToFormExtLoad() is never run. I also notice that the ARM target produces the same additional register usage (copy) and zero extending (of the copy). (See the usage of r3 &r5 and also r12 & r4 in attached file arm-strcspn.s, my understanding is that 'ldrb' is zero extending.) Here is a

...v4i32 = bitcast 0x7f91b99b0e10 [ORD=3] [ID=27] 0x7f91b99b0e10: v4i64 = insert_subvector 0x7f91b99a7210, 0x7f91b99a6d68, 0x7f91b99ace70 [ORD=2] [ID=25] 0x7f91b99a7210: v4i64 = undef [ID=15] 0x7f91b99a6d68: v2i64 = scalar_to_vector 0x7f91b99ab840 [ORD=2] [ID=23] 0x7f91b99ab840: i64 = AssertZext 0x7f91b99acc60, 0x7f91b99ac738 [ORD=2] [ID=20] 0x7f91b99acc60: i64,ch = CopyFromReg 0x7f91b8d52820, 0x7f91b99a3a10 [ORD=2] [ID=16] 0x7f91b99a3a10: i64 = Register %vreg68 [ID=1] 0x7f91b99ace70: i64 = Constant<0> [ID=3] In function: isamax0 clang: error: clang frontend com...

...cmp ne i32 %vecext4, %vecext5 %cmp7 = xor i1 %1, %cmp6 ... and the SelectionDAG before TypeLegalizer is like this. t0: ch = EntryToken t2: i32,ch = CopyFromReg t0, Register:i32 %vreg0 t3: ch = ValueType:i32 t5: i32,ch = CopyFromReg t2:1, Register:i32 %vreg1 t7: i32 = AssertZext t5, ValueType:ch:i1 t8: v2i32 = BUILD_VECTOR t2, t7 t11: v2i32 = BUILD_VECTOR Constant:i32<0>, Constant:i32<-23> t15: i32,ch = CopyFromReg t0, Register:i32 %vreg2 t22: i32 = add t15, Constant:i32<1> t24: ch = CopyToReg t0, Register:i32 %vreg3, t22...

On Sep 10, 2013, at 8:59 AM, Robert Lytton <robert at xmos.com> wrote: > 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

...w integer types would also require changing (at least): 1. TableGen/CodeGenTarget.cpp - recognize and generate code for the new types 2. LegalizeDAG.cpp - eliminate power-of-2 assumptions in the legalization of extload and truncstore operations. 3. SelectionDAGBuild.cpp - add types to assertsext/assertzext generation in getCopyFromRegs() 4. TargetLowering.cpp - eliminate power-of-2 assumptions in computeRegisterProperties() 5. <Arch>ISelLowering.cpp - specify actions to lower the new types and the operations that use them on all existing architectures (ouch!) Are there more? The main drawb...

...t; 0x7f91b99b0e10: v4i64 = insert_subvector 0x7f91b99a7210, >> 0x7f91b99a6d68, 0x7f91b99ace70 [ORD=2] [ID=25] >> 0x7f91b99a7210: v4i64 = undef [ID=15] >> 0x7f91b99a6d68: v2i64 = scalar_to_vector 0x7f91b99ab840 [ORD=2] >> [ID=23] >> 0x7f91b99ab840: i64 = AssertZext 0x7f91b99acc60, 0x7f91b99ac738 >> [ORD=2] [ID=20] >> 0x7f91b99acc60: i64,ch = CopyFromReg 0x7f91b8d52820, >> 0x7f91b99a3a10 [ORD=2] [ID=16] >> 0x7f91b99a3a10: i64 = Register %vreg68 [ID=1] >> 0x7f91b99ace70: i64 = Constant<0> [ID=3] >>...