[LLVMdev] Turning on LegalizeTypes by default

Duncan Sands baldrick at free.fr
Mon Oct 27 03:24:35 PDT 2008


Hi Chris,

> >  PowerPC/vec_spat.ll (@splat_h) - here code got slightly worse.  The
> > problem here is that LegalizeDAG "cheats": it constructs a  
> > BUILD_VECTOR
> > where the type of the operands doesn't match the vector element type  
> > (this
> > is supposed to be illegal), while LegalizeTypes correctly constructs a
> > BUILD_VECTOR where the operand type is equal to the vector element  
> > type,
> > but then the PPC custom code doesn't handle this optimally.
> 
> After looking at this a bit, I don't think this is the real reason.   
> The issue (I think) is a phase ordering issue between legalize types  
> and custom lowering.  In the old legalize case, legalize just custom  
> lowers the build_vector-of-i16 right away.  In the legalize types  
> case, legalize types modifies the DAG quite a bit to eliminate the i16  
> operations, and the PPC backend doesn't match on what it expects.

actually we were both wrong.  LegalizeDAG does call PPC custom lowering
right away, but that doesn't do anything because the element is not
constant.  It then falls through to ExpandBUILD_VECTOR.  This is
splat of one value case:

  if (SplatValue.getNode()) {   // Splat of one value?
...

The resulting scalar-to-vector and vector_shuffle then get legalized and
presumably custom lowered.  In the LegalizeTypes case we also get to
ExpandBUILD_VECTOR but this time with a v4i32 rather than a v8i16 (due
to type legalization), again in the "splat of one value" case.  However
this time subsequent legalization and custom operation lowering creates
more of a mess rather than cleaning things up.

Ciao,

Duncan.



More information about the llvm-dev mailing list