search for: 0b11

hi, i am struggling to understand how MRMDestReg is used in X86. in X86InstrFormat.td, we have this: class Format<bits<7> val> { bits<7> Value = val; } def MRMDestReg : Format<3> i think eventually, MRMDestReg is mapped back to ModMRM byte. but this still doesnt make sense to me why MRMDestReg is defined this way, and how it is mapped back to ModRM byte. any hint

...ested loops and splits the loop header in two. This is what currently happens with DOOM when we try to enable subgroup operations with it. Let's say there are two threads in a wavefront. Then the execution trace mandated by SPIR-V for the first looks like: thread 0 | thread 1 ballot 1 = 0b11 | ballot 1 = 0b11 skipped | ballot 2 = 0b10 ballot 1 = 0b11 | ballot 1 = 0b11 skipped | ballot 2 = 0b10 Now, contrast this with the execution trace that programmers would expect for the second example: thread 0 | thread 1 ballot 1 = 0b11 | ballot 1 = 0b11 ballot 1 = 0b01 |...

...d splits the loop header in two. This is what currently happens with DOOM when we try to enable subgroup operations with it. Let's say there are two threads in a wavefront. Then the execution trace mandated by SPIR-V for the first looks like: > > thread 0 | thread 1 > ballot 1 = 0b11 | ballot 1 = 0b11 > skipped | ballot 2 = 0b10 > ballot 1 = 0b11 | ballot 1 = 0b11 > skipped | ballot 2 = 0b10 > > Now, contrast this with the execution trace that programmers would expect for the second example: > > thread 0 | thread 1 > ballot 1 = 0b1...

Hi all, I try to run such a line in TableGen but seems it's not working. What is the problem with this code? multiclass cond { let Inst{1-0}=0b11 in defm fxy: ConditionalALU; .... } I receive this error: test.td:162:11: error: expected '=' in let expression let Inst{1-0}=0b11 in defm fxy: ConditionalALU; ^ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pip...

...o. This is what currently > happens with DOOM when we try to enable subgroup operations with it. Let's > say there are two threads in a wavefront. Then the execution trace mandated > by SPIR-V for the first looks like: > > > > thread 0 | thread 1 > > ballot 1 = 0b11 | ballot 1 = 0b11 > > skipped | ballot 2 = 0b10 > > ballot 1 = 0b11 | ballot 1 = 0b11 > > skipped | ballot 2 = 0b10 > > > > Now, contrast this with the execution trace that programmers would > expect for the second example: > > > > thread 0...

..., list<dag> pattern> : Instruction { ... } def int_no_operand : Intrinsic<[]>; class ALU<string opc> : TestInst<opc, "", (outs), (ins), [(int_no_operand)]>; *InstrFormat.td* multiclass Clr { def _ : ALU<"clr"> {let InstOp = 0b11;} } ----------------------------------------- after compiling the code, I receive the following error: *llvm-tblgen: /llvm/utils/TableGen/CodeGenInstruction.h:186: std::pair<unsigned int, unsigned int> llvm::CGIOperandList::getSubOperandNumber(unsigned int) const: Assertion `i < Opera...

...o. This is what currently > happens with DOOM when we try to enable subgroup operations with it. Let's > say there are two threads in a wavefront. Then the execution trace mandated > by SPIR-V for the first looks like: > > > > thread 0 | thread 1 > > ballot 1 = 0b11 | ballot 1 = 0b11 > > skipped | ballot 2 = 0b10 > > ballot 1 = 0b11 | ballot 1 = 0b11 > > skipped | ballot 2 = 0b10 > > > > Now, contrast this with the execution trace that programmers would > expect for the second example: > > > > thread 0...

...o. This is what currently > happens with DOOM when we try to enable subgroup operations with it. Let's > say there are two threads in a wavefront. Then the execution trace mandated > by SPIR-V for the first looks like: > > > > thread 0 | thread 1 > > ballot 1 = 0b11 | ballot 1 = 0b11 > > skipped | ballot 2 = 0b10 > > ballot 1 = 0b11 | ballot 1 = 0b11 > > skipped | ballot 2 = 0b10 > > > > Now, contrast this with the execution trace that programmers would > expect for the second example: > > > > thread 0...

Hi Sjoerd, For ISel, I think having a separate register class will give you less headache. I wondering if you could get away with not touching the instructions descriptions at all, instead defining external pattens for the FullFP16 case, like so: def VCVTBHS: ASuI<0b11101, 0b11, 0b0010, 0b01, 0, (outs SPR:$Sd), (ins SPR:$Sm), IIC_fpCVTSH, "vcvtb", ".f32.f16\t$Sd, $Sm", []>, Requires<[HasFP16]>, Sched<[WriteFPCVT]>; def : FP16Pat<(f16_to_fp GPR:$a),...

...appens with DOOM when we try > to enable subgroup operations with it. Let's say there are two > threads in a wavefront. Then the execution trace mandated by SPIR-V > for the first looks like: > > > > thread 0        | thread 1 > > ballot 1 = 0b11 | ballot 1 = 0b11 > > skipped        | ballot 2 = 0b10 > > ballot 1 = 0b11 | ballot 1 = 0b11 > > skipped        | ballot 2 = 0b10 > > > > Now, contrast this with the execution trace that programmers > would expect for the second example:...

...SPR, because if we would allow both f16 and f32 in SPR, then there's a choice and rules need to be typed. 3) Next, add match rules for some Armv8.2-A FP16 instructions. Instruction VADDH, which has already a tablegen description but not yet a match rules, simply becomes: def VADDH : AHbI<0b11100, 0b11, 0, 0, (outs HPR:$Sd), (ins HPR:$Sn, HPR:$Sm), IIC_fpALU16, "vadd", ".f16\t$Sd, $Sn, $Sm", [(set HPR:$Sd, (fadd HPR:$Sn, HPR:$Sm))]>, // <~~~ new match rule using HPR This is straightforward business so...

Thanks a lot for the suggestions! I will look into using vld1/vst1, sounds good. I am custom lowering the bitcasts, that's now the only place where FP_TO_FP16 and FP16_TO_FP nodes are created to avoid inefficient code generation. I will double check if I can't achieve the same without using these nodes (because I really would like to get completely rid of them). Cheers, Sjoerd.

...y > > to enable subgroup operations with it. Let's say there are two > > threads in a wavefront. Then the execution trace mandated by SPIR-V > > for the first looks like: > > > > > > thread 0 | thread 1 > > > ballot 1 = 0b11 | ballot 1 = 0b11 > > > skipped | ballot 2 = 0b10 > > > ballot 1 = 0b11 | ballot 1 = 0b11 > > > skipped | ballot 2 = 0b10 > > > > > > Now, contrast this with the execution trace that programmers > > would e...

I don't see how this would fix the continue vs. nested loop problem I explained earlier. That is, how would this prevent turning: for (...) { ballot(); if (... /* non-uniform */) continue; } into for (...) { do { ballot(); } while (... /* non-uniform */); } and vice versa? Note that there's no duplication going on here, and the single-threaded flow of control is

...t<list<dag> P = [], string C = ""> : JRInst <(outs), (ins PredRegs:$Pu, IntRegs:$Rs), "if (!$Pu.new) jumpr:t $Rs", P, C> { bits<2> Pu; bits<5> Rs; IClass = 0b0101; Inst{27-21} = 0b0011011; Inst{12-11} = 0b11; Inst{9-8} = Pu; Inst{20-16} = Rs; }; let isReturn = 1, isBarrier = 1, isTerminator = 1 in def JMPR_cdnNotPt_V3 : V3_J2_jumprfnewpt<>, Requires<[HasV3T]>; The insn class would be in a separate file included in the file where the insns are defin...

...;.outsDefault, IO_MultSrc<op0t, SpecialReg>.insDefault>; ... } multiclass TwoSrcOneDestSpec<bits<5> subOpcode, string opcodeStr> { defm _dds: MultSrc1Spec<subOpcode, 0b10, opcodeStr, SpecialReg>; ... defm _rr: MultSrc1Spec<subOpcode, 0b11, opcodeStr, GPReg>; } defm ADD : TwoSrcOneDestSpec<0b10000, "add">; I currently get the error "Undefined reference:'ADDanonymous_545'" when I try to generate. Any advice would be greatly appreciated, even if that advice is "don't try to conditional...