[llvm-commits] [PATCH] Fix PR11334

Michael Liao michael.liao at intel.com
Wed Jul 25 13:17:10 PDT 2012


Hi 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.

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

As a RFC, is it possible to relax the constrain on FP_EXTEND, FP_ROUND,
and etc to must have matching element numbers. It should be quite common
for target to reuse a single physical register for vector types
(extendable) but with different elements. We could refine the constrain
on FP_EXTEND to ensure the input vector has more elements than the
output elements. This way, we could construct legal 'fpext' from v4f32
to v2f64.

Yours
- Michael

On Wed, 2012-07-25 at 12:58 -0700, Rotem, Nadav wrote:
> Hi Michael, 
> 
> In your patch you are counting on the type-legalizer to scalarize the FPEXT operation, only to gether it again. I think that the pre-type-legalization DAGCombine code would be short and simple.  Why not implement a DAGCombine optimization which works on vector FPEXT ISDs ?  I understand that it will be more difficult to handle types such as <3 x float>, but are these really important ?   
> 
> Thanks,
> Nadav
> 
> -----Original Message-----
> From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-bounces at cs.uiuc.edu] On Behalf Of Michael Liao
> Sent: Wednesday, July 25, 2012 00:28
> To: llvm-commits at cs.uiuc.edu
> Subject: [llvm-commits] [PATCH] Fix PR11334
> 
> Hi
> 
> Please review the attached patch fixing PR11334. With this patch, the test case in PR11334 could generate the expected insn, CVTPS2PD instead of series of CVTSS2SD. An enhanced test case is included as well.
> 
> Yours
> - Michael





More information about the llvm-commits mailing list