Displaying 5 results from an estimated 5 matches for "opcstrm".
Did you mean:
opcstr
2011 Oct 07
0
[LLVMdev] Enhancing TableGen
...ng 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),
> binary_pattern<opcstrm "f32">.pattern, []>;
> def rr64 : InstPTX<(outs RegF64:$d),
>...
2011 Oct 07
6
[LLVMdev] Enhancing TableGen
...r, 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),
binary_pattern<opcstrm "f32">.pattern, []>;
def rr64 : InstPTX<(outs RegF64:$d),
(ins RndMode...
2011 Oct 07
0
[LLVMdev] Enhancing TableGen
On Oct 7, 2011, at 11:23 AM, David A. Greene wrote:
> Evan Cheng <evan.cheng at apple.com> writes:
>
>> Your proposed new TableGen functionalities are interesting but it is
>> clearly not where the code owners want it to go.
>
> Jakob at least seems interested in the for loop stuff. Am I reading you
> correctly, Jakob? Having that feature would make a huge
2011 Oct 08
3
[LLVMdev] Enhancing TableGen
...(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),
>> binary_pattern<opcstrm "f32">.pattern, []>;
>> def rr64 : InstPTX<(outs RegF64:$d),
&...
2011 Oct 07
6
[LLVMdev] Enhancing TableGen
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