[llvm-commits] [PATCH] Fix PR11334

[Michael Liao]

committed as r161894

On Tue, 2012-08-14 at 13:50 -0700, Evan Cheng wrote:
> It looks fine to me. 
> 
> Thanks,
> 
> Evan
> 
> On Aug 13, 2012, at 2:15 PM, Michael Liao <michael.liao at intel.com> wrote:
> 
> > Hi
> > 
> > Here is the revised patch fixing PR11334. The new patch adds a
> > target-specific BUILD_VECTOR lowering to recover original vector FP
> > extending instead of DAG combining to reduce the overhead of DAG
> > combination.
> > 
> > Yours
> > - Michael
> > 
> > On Thu, 2012-08-02 at 13:16 -0700, Michael Liao wrote:
> >> Hi
> >> 
> >> Just ping again for code review and suggestions.
> >> 
> >> Yours
> >> - Michael
> >> 
> >> On Mon, 2012-07-30 at 16:01 -0700, Michael Liao wrote:
> >>> Hi
> >>> 
> >>> Please find the revised patch attached. Changes includes
> >>> 
> >>> + a minor fix to quit if a non-constant index is found in
> >>> extract-vector-elt node
> >>> + rebase the code to the current trunk code
> >>> 
> >>> The reason why I choose to recover the scalarized FP_EXTEND back instead
> >>> of do a pre-type-legalization transformation directly from FP_EXTEND to
> >>> X86ISD::VFPEXT is to leverage the existing target-independent DAG
> >>> optimization as much as possible till FP_EXTEND is scalaried into
> >>> BUILD_VECTOR. Even though it makes the code a little complicated
> >>> (recognizing FP_EXTEND pattern from the BUILD_VECTOR and series of
> >>> scalarized EXTRACT_VEC_ELTs), it won't break the optimization like
> >>> (fp_round (fp_extend x)) -> x and etc. It also supports extending v4f32
> >>> -> v4f64 better as well as from v3f32 to v3f64.
> >>> 
> >>> Please commit if it looks OK.
> >>> 
> >>> Thanks
> >>> - Michael
> >>> 
> >>> 
> >>> On Wed, 2012-07-25 at 13:31 -0700, Michael Liao wrote:
> >>>> Typo
> >>>> 
> >>>> On Wed, 2012-07-25 at 13:29 -0700, Michael Liao wrote:
> >>>>> On Wed, 2012-07-25 at 13:24 -0700, Rotem, Nadav wrote:
> >>>>>>>> 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. 
> >>>>> 
> >>>>> The optimization is only targeted to optimize the case for FP_EXTEND. In
> >>>> 
> >>>> is not only target to optimize this bug.
> >>>> 
> >>>>> case of a user code constructs the similar pattern, it would be
> >>>>> optimized as well. Note the extra shuffle node in the patch, if pattern
> >>>>> constructed including non-identify shuffle (by constructing a series of
> >>>>> extract elements), it could be optimized as well to construct a shuffle
> >>>>> followed by a conversion.
> >>>>> 
> >>>>>> 
> >>>>>>>> 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.
> >>>>>> 
> >>>>> 
> >>>>> <3 x float> is solved as by-product. The main case is to fix <2 x
> >>>>> float>. If the user code uses <2 x double> for most cases but only
> >>>>> several places need converting from float. It's better to use <2 x
> >>>>> float> for that values.
> >>>>> 
> >>>>> Yours
> >>>>> - Michael
> >>>>> 
> >>>>> _______________________________________________
> >>>>> llvm-commits mailing list
> >>>>> llvm-commits at cs.uiuc.edu
> >>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> >>>> 
> >>>> 
> >>>> _______________________________________________
> >>>> llvm-commits mailing list
> >>>> llvm-commits at cs.uiuc.edu
> >>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> >>> 
> >>> _______________________________________________
> >>> llvm-commits mailing list
> >>> llvm-commits at cs.uiuc.edu
> >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> >> 
> >> 
> >> _______________________________________________
> >> llvm-commits mailing list
> >> llvm-commits at cs.uiuc.edu
> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> > 
> > <0001-fix-PR11334.patch>_______________________________________________
> > llvm-commits mailing list
> > llvm-commits at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>