[llvm-commits] [PATCH] Fix PR11334

[Rotem, Nadav]

>>In fact, the real root cause from my understanding is that ISD::FP_EXTEND (including others as well) has the constraint that the input and output vectors must have matching >>element numbers. 'v2f32' is not legal on x86 and there is way to construct a legal FP_EXTEND from
>>v2f32 to v2f64. This lead to the scalarization of FP_EXTEND during type legalization. The added optimization is to recover it back and re-construct that extending using a target->>specific without that constrain.

Yes. But you don’t need to reconstruct the vector, if you can handle it before it gets scalarized.  All you have to do is transform the FP_EXTEND node to your own X86ISD node. 
The inputs to your ISD nodes would be v4f32, and the output would be v2f64. 

>> For <3 x float>, it will be legailized (widened) into v4f32. The test included verified that.

Right, the question is, how important is it to support this type ? Because, if we handle FP_EXTEND before type-legalization, then it would be a bit more difficult to handle this type.

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.