search for: regf32

...itive cost to understand macro expansion, since it removes a lot of redundancy, I think it is actually more readable. (excerpt of PTXInstrInfo.td) ---------------------------------------- multiclass PTX_FLOAT_4OP<string opcstr, SDNode opnode1, SDNode opnode2> { def rrr32 : InstPTX<(outs RegF32:$d), (ins RegF32:$a, RegF32:$b, RegF32:$c), !strconcat(opcstr, ".f32\t$d, $a, $b, $c"), [(set RegF32:$d, (opnode2 (opnode1 RegF32:$a, RegF32:$b),...

...that can create them. I think this > was the primary motivation behind Che-Liang's proposal. Ok. We agree here. > I do NOT want to factor out redundancy from instruction definitions like this: > > multiclass PTX_FLOAT_3OP<string opcstr> { > def rr32 : InstPTX<(outs RegF32:$d), > (ins RndMode:$r, RegF32:$a, RegF32:$b), > !strconcat(opcstr, "$r.f32\t$d, $a, $b"), []>; > def ri32 : InstPTX<(outs RegF32:$d), > (ins RndMode:$r, RegF32:$a, f32imm:$b), > !st...

...ue, and I would welcome a for-loop construct that can create them. I think this was the primary motivation behind Che-Liang's proposal. I do NOT want to factor out redundancy from instruction definitions like this: multiclass PTX_FLOAT_3OP<string opcstr> { def rr32 : InstPTX<(outs RegF32:$d), (ins RndMode:$r, RegF32:$a, RegF32:$b), !strconcat(opcstr, "$r.f32\t$d, $a, $b"), []>; def ri32 : InstPTX<(outs RegF32:$d), (ins RndMode:$r, RegF32:$a, f32imm:$b), !strconcat(opcstr, "$r....

...ed somewhat by doing something like this: > > class binary_pattern<string opcstr, string type> { > string pattern = !strconcat(opcstr, "$r."#type#"\t$d, $a, $b"); > } > > multiclass PTX_FLOAT_3OP<string opcstr> { > def rr32 : InstPTX<(outs RegF32:$d), > (ins RndMode:$r, RegF32:$a, RegF32:$b), > binary_pattern<opcstrm "f32">.pattern, []>; > def ri32 : InstPTX<(outs RegF32:$d), > (ins RndMode:$r, RegF32:$a, f32imm:$b), > binar...

...TableGen definitions? Let's say I have the following pattern: def : Pat<(i1 (trunc RegI16:$a)), (SETPGTu16ri RegI16:$a, 0)>; Note the zero constant in the result. Is there a way to represent floating-point literals in the same way? Something like... def : Pat<(i1 (uint_to_fp RegF32:$a)), (SETPGTf32ri RegF32:$a, (f32 0.0))>; This unfortunately does not work. Right now I'm getting around this by using alternate instructions to first convert from an integer immediate, something like: def : Pat<(i1 (uint_to_fp RegF32:$a)), (SETPGTf32ri RegF32:$a, (MOVf32i32...

Evan Cheng <evan.cheng at apple.com> writes: > David, we cannot accept the 'multidef' keyword. Please revert it. Working on it now. > We appreciate you thinking ahead about MIC, but we are against the > massive refactoring and complicated abstraction scheme. We'll never > accept those patches. How about a less massive and complicated scheme? I think we can make

...to be too limiting. In this example: (Equivalent TableGen code 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"),...

...hing like this: >> >> class binary_pattern<string opcstr, string type> { >>  string pattern = !strconcat(opcstr, "$r."#type#"\t$d, $a, $b"); >> } >> >> multiclass PTX_FLOAT_3OP<string opcstr> { >>  def rr32 : InstPTX<(outs RegF32:$d), >>                     (ins RndMode:$r, RegF32:$a, RegF32:$b), >>                     binary_pattern<opcstrm "f32">.pattern, []>; >>  def ri32 : InstPTX<(outs RegF32:$d), >>                     (ins RndMode:$r, RegF32:$a, f32imm:$b), >>      ...

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

Hi, Current register class naming has a confusing prefix letter 'R' (it is my bad), such as the first 'R' of RRegu32 (for unsigned 32-bit registers). I propose a 'Reg' + type name naming convention for register classes; such as: Regu16, Regu32, Regf32, Regf64 With one exception for predicate registers (capitalized first letter of 'pred'): RegPred Since predicate registers are special in the way that they can't be passed as arguments or load from/store to memory, I think a little name convention exception for it is okay. What do y...

...his: > > (Equivalent TableGen code 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 !strconcat(!strconcat("rr", !cast<string>(op_suffix)), "nbit") > [...] > } > } > > Yes, it's a bit more verbose but also more flexible in what yo...

...t; > Current register class naming has a confusing prefix letter 'R' (it is > my bad), such as the first 'R' of RRegu32 (for unsigned 32-bit > registers). > > I propose a 'Reg' + type name naming convention for register classes; such as: > Regu16, Regu32, Regf32, Regf64 > With one exception for predicate registers (capitalized first letter of 'pred'): > RegPred > > Since predicate registers are special in the way that they can't be > passed as arguments or load from/store to memory, I think a little > name convention excepti...

...ss naming has a confusing prefix letter 'R' (it is >> my bad), such as the first 'R' of RRegu32 (for unsigned 32-bit >> registers). >> >> I propose a 'Reg' + type name naming convention for register classes; such >> as: >> Regu16, Regu32, Regf32, Regf64 >> With one exception for predicate registers (capitalized first letter of >> 'pred'): >> RegPred >> >> Since predicate registers are special in the way that they can't be >> passed as arguments or load from/store to memory, I think a little...

...g prefix letter 'R' (it is >>> my bad), such as the first 'R' of RRegu32 (for unsigned 32-bit >>> registers). >>> >>> I propose a 'Reg' + type name naming convention for register classes; >>> such as: >>> Regu16, Regu32, Regf32, Regf64 >>> With one exception for predicate registers (capitalized first letter of >>> 'pred'): >>> RegPred >>> >>> Since predicate registers are special in the way that they can't be >>> passed as arguments or load from/store to m...

...naming has a confusing prefix letter 'R' (it is<br> my bad), such as the first 'R' of RRegu32 (for unsigned 32-bit<br> registers).<br> <br> I propose a 'Reg' + type name naming convention for register classes; such as:<br>  Regu16, Regu32, Regf32, Regf64<br> With one exception for predicate registers (capitalized first letter of 'pred'):<br>  RegPred<br> <br> Since predicate registers are special in the way that they can't be<br> passed as arguments or load from/store to memory, I think a litt...

...to be too limiting. In this example: (Equivalent TableGen code 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"),...