Displaying 5 results from an estimated 5 matches for "x86valuetype".
2009 Jun 15
2
[LLVMdev] Regular Expressions
Chris Lattner wrote:
> However, I don't see any reason to base this off of strings. Instead
> of passing down "f32" as a string, why not do something like this
> pseudo code:
>
> class X86ValueType {
> RegisterClass RegClass;
> ...
> }
>
> def X86_f32 : X86ValueType {
> let RegClass = FR32;
> ... };
> def X86_i32 : X86ValueType { ... };
>
> Then change fp_cvt_scalar_VXSnrr to be something like this:
>
>> class fp_cvt_scalar_VXSnrr<
>...
2009 Jun 13
0
[LLVMdev] Regular Expressions
...gt; a smaller amount of information.
Right, I definitely agree with your goal of reducing redundancy in
the .td files! :)
However, I don't see any reason to base this off of strings. Instead
of passing down "f32" as a string, why not do something like this
pseudo code:
class X86ValueType {
RegisterClass RegClass;
...
}
def X86_f32 : X86ValueType {
let RegClass = FR32;
... };
def X86_i32 : X86ValueType { ... };
Then change fp_cvt_scalar_VXSnrr to be something like this:
> class fp_cvt_scalar_VXSnrr<
> // Parent: avx_fp_cvt_scalar_xs_node_rm_DEF_V#NAME#_128rr...
2009 Jun 15
0
[LLVMdev] Regular Expressions
On Jun 15, 2009, at 11:33 AM, David Greene wrote:
> To reduce redundancy, developers must be able to write generic
> patterns
> like this:
>
> [(set DSTREGCLASS:$dst, // rr, rrr
> (xor (INTSRCTYPE (bitconvert (SRCTYPE SRCREGCLASS:$src1))),
> (INTSRCTYPE (bitconvert (SRCTYPE SRCREGCLASS:$src2)))))],
>
> The substitution then fills in the appropriate types,
2009 Jun 11
2
[LLVMdev] Regular Expressions
On Thursday 11 June 2009 12:28, Chris Lattner wrote:
> On Jun 9, 2009, at 12:39 PM, David Greene wrote:
> > On Tuesday 09 June 2009 14:34, Dan Gohman wrote:
> >> Can you describe what problem you're trying to solve here? Does it
> >> really need Regular Expressions?
> >
> > Yes. I want TableGen to be able to infer lots of stuff
> >
2009 Jun 17
3
[LLVMdev] Regular Expressions
...e redundancy.
>
> Why not synthesize the opcode string from the information passed down?
That's actually how I started things out initially. The problem is that it
leads to a less intuitive specification. I'll see if I can illustrate.
Say we have a wrapper class like this:
class X86ValueType {
ValueType VT;
RegisterClass RegClass;
string suffix;
}
Now we instantiate some concrete types:
class X86_f32 : X86ValueType {
let VT = f32;
let RegClass = FR32;
let suffix = "ss";
}
class X86_v4f32 : X86ValueType {
let VT = v4f32;
let RegClass = VR128;
let suf...