search for: opvt

...t clarified anyway. I am using a pattern from X86InstrFMA.td in the below example. Consider FMA3 pattern (simplified). let Constraints = "$src1 = $dst" in { multiclass fma3s_rm<bits<8> opc, string OpcodeStr, X86MemOperand x86memop, RegisterClass RC, ValueType OpVT, PatFrag mem_frag, SDPatternOperator OpNode = null_frag> { def r : FMA3<opc, MRMSrcReg, (outs RC:$dst), (ins RC:$src1, RC:$src2, RC:$src3), !strconcat(OpcodeStr, "\t{$src3, $src2, $dst|$dst, $s...

...g a pattern from > X86InstrFMA.td in the below example. Consider FMA3 pattern > (simplified). > > let Constraints = "$src1 = $dst" in { > multiclass fma3s_rm<bits<8> opc, string OpcodeStr, X86MemOperand x86memop, > RegisterClass RC, ValueType OpVT, PatFrag mem_frag, > SDPatternOperator OpNode = null_frag> { > > def r : FMA3<opc, MRMSrcReg, (outs RC:$dst), > (ins RC:$src1, RC:$src2, RC:$src3), > !strconcat(OpcodeStr, > "\...

...s now type i64, even though I want the MUL I32 to remain as an operation in the architecture. MUL i32 would generate a 64-bit results from the lower 32-bit portions of 64-bit source operands. In customize for the operations, I am trying to do something like: case ISD::MUL: { EVT OpVT = Op.getValueType(); if (OpVT == MVT::i64) { RTLIB::Libcall LC = RTLIB::MUL_I64; SDValue Dummy; return ExpandLibCall(LC, Op, DAG, false, Dummy, *this); } else if (OpVT == MVT::i32){ ??? What to do here to not have issues...

...he pattern to be dropped. Now having covered that the reason the operands are in the order they are is because the only instruction that doesn't use null_frag is this one defm r213 : fma3s_rm<opc213, !strconcat(OpStr, !strconcat("213", PackTy)), x86memop, RC, OpVT, mem_frag, OpNode> Which specifies the operand order as 213 thus why they are 2, 1, 3 in the pattern. ~Craig On Fri, Nov 16, 2012 at 12:19 AM, Anitha B Gollamudi < anitha.boyapati at gmail.com> wrote: > On 16 November 2012 13:41, Anitha B Gollamudi <anitha.boyapati at gmail.com&g...

...UL I32 > to remain as an operation in the architecture. MUL i32 would generate a > 64-bit results from the lower 32-bit portions of 64-bit source operands. > > In customize for the operations, I am trying to do something like: > > case ISD::MUL: > { > EVT OpVT = Op.getValueType(); > if (OpVT == MVT::i64) { > RTLIB::Libcall LC = RTLIB::MUL_I64; > SDValue Dummy; > return ExpandLibCall(LC, Op, DAG, false, Dummy, *this); > } > else if (OpVT == MVT::i32){ > >...

...tion in the architecture. MUL i32 would generate a > > 64-bit results from the lower 32-bit portions of 64-bit source operands. > > > > In customize for the operations, I am trying to do something like: > > > > case ISD::MUL: > > { > > EVT OpVT = Op.getValueType(); > > if (OpVT == MVT::i64) { > > RTLIB::Libcall LC = RTLIB::MUL_I64; > > SDValue Dummy; > > return ExpandLibCall(LC, Op, DAG, false, Dummy, *this); > > } > > else if (OpVT == MV...

Hi Dale, I think Bob is right: the type legalizer shouldn't be turning v16i8 into v16i32, what should happen is that the return type of the BUILD_VECTOR continues to be v16i8, but the type of the operands changes to i32, so you end up with a BUILD_VECTOR that takes 16 lots of i32, and produces a v16i8. The target then has all the info it needs to produce the best code, but needs to be careful

On Wed, Nov 7, 2012 at 10:52 PM, Anitha Boyapati <anitha.boyapati at gmail.com>wrote: ... > For the multiclass "fma4s", why is "mr" not inherited from "VEX_W" and > "MemOp4" like those of "rm" or "rr" ? > Hey Anitha, The VEX.W bit is used to denote operand order. In other words, this bit allows for a memop to be used as

Hi, A question from r162999 changes: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/X86/X86InstrFMA.td?r1=162999&r2=162998&pathrev=162999 For the multiclass "fma4s", why is "mr" not inherited from "VEX_W" and "MemOp4" like those of "rm" or "rr" ? multiclass fma4s< > ... def mr : FMA4<opc, MRMSrcMem, (outs

Thanks Dragos, I assume I will be setting those parameters during initialization of encoder right? Question is, if connection gets too lossy, how will opus adapt to it? Can it automatically shift bitrate down to minimize impact? Mark from IRC suggests that the app has to be aware of the losses and change it on the fly. Has anybody on the list tried this? Kelvin Chua On Wed, Mar 4, 2015 at 5:53

...ex_w help in instruction selection in-addition to FMA4 class? [3]. Why does only "rr" and "rm" forms have vex_w but not "mr" ? (Reference) multiclass fma4s<bits<8> opc, string OpcodeStr, RegisterClass RC, X86MemOperand x86memop, ValueType OpVT, SDNode OpNode, PatFrag mem_frag> { def rr : FMA4<opc, MRMSrcReg, (outs RC:$dst), (ins RC:$src1, RC:$src2, RC:$src3), !strconcat(OpcodeStr, "\t{$src3, $src2, $src1, $dst|$dst, $src1, $src2, $src3}"), [(set RC:$dst,...

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

...oc(), MVT::i64, LHS, RHS); In order to get the operation to be able to be able to go forward and match the new operation with the input operands (which were still I32 and not yet type-legalized to i64). Does this make sense to you? Here's what I am using to generate the XXXISD::MUL32: if(OpVT != MVT::i64) { //Op.getNode()->dumpr(); SDValue LHS = Op.getOperand(0); SDValue RHS = Op.getOperand(1); LHS = DAG.getNode(ISD::ZERO_EXTEND, dl, MVT::i64, LHS); RHS = DAG.getNode(ISD::ZERO_EXTEND, dl, MVT::i64, RHS); return...