search for: my_f32

...gt; clear to me what those multiple types mean. I might think they're > source > and destination types, for example. I think I understand what you're saying with "munging strings is easier". However, I still don't understand why you can't pass down some 'my_f32' instead of '"f32"' and have the defm pull out the right fields from my_f32. The AVX type would be v8f32, the SSE type would be v4f32, etc. More generally, I don't see how strings can be better in any circumstance: in any case where you pass down a string, you can...

On Wednesday 17 June 2009 01:06, Chris Lattner wrote: > I think I understand what you're saying with "munging strings is > easier". However, I still don't understand why you can't pass down > some 'my_f32' instead of '"f32"' and have the defm pull out the right > fields from my_f32. The AVX type would be v8f32, the SSE type would > be v4f32, etc. > > More generally, I don't see how strings can be better in any > circumstance: in any case where you pass down...

On Tuesday 16 June 2009 19:35, David Greene wrote: > So which is more intuitive and less error-prone? > > defm BLENDPS : sse41_avx_fp_binary_vector_osta_vintrinsic_rmi_rrmi<0x0C, > i32i8imm, "blend", "blend", "f32", 4>; > > or > > defm BLENDPS : sse41_avx_fp_binary_vector_osta_vintrinsic_rmi_rrmi<0x0C, >

On Monday 15 June 2009 14:35, Chris Lattner wrote: > > I suppose you could argue that additional parameters specifying > > the source and dest types could be passed, but why bother when > > it is already encoded in the mnemonic? That would just be > > adding error-prone redundancy. > > Why not synthesize the opcode string from the information passed down?