search for: fpimm

...de with a for-loop) ---------------------------------------- multiclass PTX_FLOAT_4OP<string opcstr, SDNode opnode1, SDNode opnode2> { for nbit = [32, 32, 64, 64], op_suffix = [r, i, r, i], op_type = [RegF32, f32imm, RegF64, f64imm], op_node_type = [RegF32, fpimm, RegF64, fpimm] in { def rr#op_suffix#nbit : InstPTX<(outs RegF#nbit:$d), (ins RegF#nbit:$a, RegF#nbit:$b, #op_type:$c), !strconcat(opcstr, ".f#nbit\t$d, $a, $b, $c"), [(set RegF#nbit:$d, (opnode2 (opnode1 Reg...

...ns RegF32:$a, RegF32:$b, f32imm:$c), !strconcat(opcstr, ".f32\t$d, $a, $b, $c"), [(set RegF32:$d, (opnode2 (opnode1 RegF32:$a, RegF32:$b), fpimm:$c))]>; def rrr64 : InstPTX<(outs RegF64:$d), (ins RegF64:$a, RegF64:$b, RegF64:$c), !strconcat(opcstr, ".f64\t$d, $a, $b, $c"), [(set RegF64:$d, (opnode2 (opnode1 RegF64:$a,...

Jakob Stoklund Olesen <jolesen at apple.com> writes: > The TableGen language seems to be growing Lisp macros from two > different directions. > > Che-Liang Chiou added a preprocessor with for loops, and David Greene > added multidefs. > > It seems that some kind of macro facility is needed, perhaps we should > discuss what it is supposed to look like? Don't

The TableGen language seems to be growing Lisp macros from two different directions. Che-Liang Chiou added a preprocessor with for loops, and David Greene added multidefs. It seems that some kind of macro facility is needed, perhaps we should discuss what it is supposed to look like? /jakob

...----------------------------------- > multiclass PTX_FLOAT_4OP<string opcstr, SDNode opnode1, SDNode opnode2> { > for nbit = [32, 32, 64, 64], > op_suffix = [r, i, r, i], > op_type = [RegF32, f32imm, RegF64, f64imm], > op_node_type = [RegF32, fpimm, RegF64, fpimm] in { > def !strconcat(!strconcat("rr", !cast<string>(op_suffix)), "nbit") > [...] > } > } > > Yes, it's a bit more verbose but also more flexible in what you can do > with iterator values. Here's some more detail on...

...Segmentation fault (core dumped) ==== 2) Second test case: double inclusion of file, that is definitely included once: ==== $ ./llvm-tblgen -gen-tgt-intrinsic NVPTX2.td Included from NVPTX2.td:20: NVPTXIntrinsics.td:10:1: error: def 'immFloat0' already defined def immFloat0 : PatLeaf<(fpimm), [{ ^ NVPTX1.td differs from NVPTX2.td just in one line: include "NVPTXIntrinsics.td" ==== Expected behavior ==== 1) In first case, where .td file has empty list of intrinsics, the tool should not crash 2) In second case there should not me an error message about already defined symb...

...> 2) Second test case: double inclusion of file, that is definitely included > once: > ==== > > $ ./llvm-tblgen -gen-tgt-intrinsic NVPTX2.td > Included from NVPTX2.td:20: > NVPTXIntrinsics.td:10:1: error: def 'immFloat0' already defined > def immFloat0 : PatLeaf<(fpimm), [{ > ^ $ llvm-tblgen -gen-tgt-intrinsic NVPTX2.td Included from NVPTX2.td:18: NVPTXRegisterInfo.td:32:14: error: Value list is not of list type foreach i = 0-395 in { ^ Included from NVPTX2.td:18: NVPTXRegisterInfo.td:32:14: error: expected declaration in for foreach i = 0-395 in...

You can tell LLVM that you have "sign extended" setCC results (all ones). Dan On Nov 18, 2008, at 5:33 PM, Eli Friedman wrote: > On Tue, Nov 18, 2008 at 1:56 PM, Villmow, Micah > <Micah.Villmow at amd.com> wrote: >> The IR produces correct results, but my backend does not and the >> only thing >> I can think of is that the IR is treating the

Hi, I'm implementing the built_vector as an IMPLICIT_DEF followed by INSERT_SUBREGs. This approach is the one of the SPARC architecture. def : Pat<(build_vector (f32 fpimm:$a1), (f32 fpimm:$a2)), (INSERT_SUBREG(INSERT_SUBREG (v2f32 (IMPLICIT_DEF)), (i32 (COPY_TO_REGCLASS (MOVSUTO_A_iSLo (bitcast_fpimm_to_i32 f32:$a1)), FPUaOffsetClass)), A_UNIT_PART), (i32 (COPY_TO_REGCLASS (MOVSUTO_A_iSLo (bitcast_fpimm_to_i32 f32:$a2)), FPU...

I tried to generate pattern for instruction which transports floating point immediate to a floating point register. def MOVF32fk : InstTCE<(outs F32Regs:$dst), (ins f32imm:$val), "$val -> $dst;", [(set F32Regs:$dst, (f32 imm:$val))]>; This causes an type contradiction:

...de with a for-loop) ---------------------------------------- multiclass PTX_FLOAT_4OP<string opcstr, SDNode opnode1, SDNode opnode2> { for nbit = [32, 32, 64, 64], op_suffix = [r, i, r, i], op_type = [RegF32, f32imm, RegF64, f64imm], op_node_type = [RegF32, fpimm, RegF64, fpimm] in { def rr#op_suffix#nbit : InstPTX<(outs RegF#nbit:$d), (ins RegF#nbit:$a, RegF#nbit:$b, #op_type:$c), !strconcat(opcstr, ".f#nbit\t$d, $a, $b, $c"), [(set RegF#nbit:$d, (opnode2 (opnode1 Reg...

...t;, [(set (i64 GRWideRegs:$dst), imm:$src)]>{ let isMoveImm = 1; } def CONSTF64 : InstFOO<(outs GRWideRegs:$dst), (ins f64imm:$src), "const-double $dst, $src", [(set (f64 GRWideRegs:$dst), fpimm:$src)]>{ let isMoveImm = 1; } GRWideRegs can be f64 and i64. However, the 'const-long' works while the 'const-double' doesn't work. From the -debug log, it seems "f64 = ConstantFP" is replaced by "f64,ch = load" and this is where the error happens. Can...

...as removed in r116644. If you try to add back a case for them in the obvious way, getBinaryCodeForInstr() (which now ostensibly should handle this and has a case for it) asserts constructing the instruction because getMachineOpValue(MI, MI,getOperand(1)) doesn't handle a MachineOperand of type FPImm. I'm not sure what the right way to fix these last to issues is. Is any regression testing done at all for JIT support on non-X86 platforms? It seems like a simple cross-compilation framework could be set up to allow such targets to be sanity-tested without needing an actual CPU to run one....

Hi Jim, thank you for the quick response. I have used InstAlias in some cases, but these are really simple pseudo instructions where the pseudo instruction is more like a special case of existing one, like using fixed operand or simply a more human understandable way of presenting an operation. I know that there are predicates available to improve matching, but can InstAlias use conditions to

...16<0>, t41:1 t43: ch = CLPISD::RET_FLAG t42:1 ISEL: Starting pattern match on root node: t50: i32 = Constant<1065353216> Initial Opcode index to 415 TypeSwitch[i32] from 416 to 432 Morphed node: t50: i32 = MOVSUTO_A_iSLo TargetConstant:i32<1065353216> def : Pat<(f32 fpimm:$imm), (MOVSUTO_A_iSLo (bitcast_fpimm_to_i32 f32:$imm))>; def : Pat<(i32 imm:$imm), (MOVSUTO_A_iSLo (trunc_imm i32:$imm))>; ===== Instruction selection ends: Selected selection DAG: BB#0 '_start:entry' SelectionDAG has 42 nodes:...

...2:1 > > ISEL: Starting pattern match on root node: t50: i32 = Constant<1065353216> > >   Initial Opcode index to 415 > >   TypeSwitch[i32] from 416 to 432 > > Morphed node: t50: i32 = MOVSUTO_A_iSLo TargetConstant:i32<1065353216> > > def: Pat<(f32 fpimm:$imm), > >                         (MOVSUTO_A_iSLo (bitcast_fpimm_to_i32 f32:$imm))>; > > def: Pat<(i32 imm:$imm), > >                         (MOVSUTO_A_iSLo (trunc_imm i32:$imm))>; > > ===== Instruction selection ends: > > Selected selection DAG: BB#0...

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

...t; > ISEL: Starting pattern match on root node: t50: i32 = > Constant<1065353216> > >   Initial Opcode index to 415 > >   TypeSwitch[i32] from 416 to 432 > > Morphed node: t50: i32 = MOVSUTO_A_iSLo TargetConstant:i32<1065353216> > > def: Pat<(f32 fpimm:$imm), > >                         (MOVSUTO_A_iSLo (bitcast_fpimm_to_i32 > f32:$imm))>; > > def: Pat<(i32 imm:$imm), > >                         (MOVSUTO_A_iSLo (trunc_imm i32:$imm))>; > > ===== Instruction selection ends: > > Selected selection DAG...

Hi, We are now about halfway between the 3.4 and 3.5 releases, and I would like to start preparing for a 3.4.1 release. Here is my proposed release schedule: Mar 26 - April 9: Identify and backport additional bug fixes to the 3.4 branch. April 9 - April 18: Testing Phase April 18: 3.4.1 Release How you can help: - If you have any bug fixes you think should be included to 3.4.1, send me an

...asm, pattern> { > + > + field bits<32> Inst = 0xffffffff; > + > +} > + > +class Constants { > +int TWO_PI = 0x40c90fdb; > +int PI = 0x40490fdb; > +int TWO_PI_INV = 0x3e22f983; > +} > +def CONST : Constants; > + > +def FP_ZERO : PatLeaf < > + (fpimm), > + [{return N->getValueAPF().isZero();}] > +>; > + > +def FP_ONE : PatLeaf < > + (fpimm), > + [{return N->isExactlyValue(1.0);}] > +>; > + > +let isCodeGenOnly = 1, isPseudo = 1, usesCustomInserter = 1 in { > + > +class CLAMP <RegisterClass...