[llvm] r185794 - Fix PromoteIntRes_BUILD_VECTOR crash with i1 vectors
Hal Finkel
hfinkel at anl.gov
Mon Jul 8 06:37:05 PDT 2013
Hi Duncan,
----- Original Message -----
> Hi Hal,
>
> On 08/07/13 08:16, Hal Finkel wrote:
> > Author: hfinkel
> > Date: Mon Jul 8 01:16:58 2013
> > New Revision: 185794
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=185794&view=rev
> > Log:
> > Fix PromoteIntRes_BUILD_VECTOR crash with i1 vectors
> >
> > This fixes a bug (found by llvm-stress) in
> > DAGTypeLegalizer::PromoteIntRes_BUILD_VECTOR where it assumed that
> > the result
> > type would always be larger than the original operands.
>
> yes, integer build vector operands can essentially be arbitrarily
> bigger than
> the result element type:
>
> /// BUILD_VECTOR(ELT0, ELT1, ELT2, ELT3,...) - Return a vector
> with the
> /// specified, possibly variable, elements. The number of
> elements is
> /// required to be a power of two. The types of the operands
> must all be
> /// the same and must match the vector element type, except that
> integer
> /// types are allowed to be larger than the element type, in
> which case
> /// the operands are implicitly truncated.
> BUILD_VECTOR,
>
> This is not always
> > true, however, with boolean vectors. For example, promoting a node
> > of type v8i1
> > (where the operands will be of type i32, the type to which i1 is
> > promoted) will
> > yield a node with a result vector element type of i16 (and operands
> > of type
> > i32).
>
> That doesn't sound like a bug, since BUILD_VECTOR explicitly allows
> the
> operands to be bigger than the result element type (see above).
> However
> your patch seems to be dealing with the opposite problem (if I read
> it
> right): a BUILD_VECTOR where the result element type is larger than
> the
> input operand type. So I'm kind of confused by your description and
> the
> comment in the code, since it doesn't seem to match what the patch
> does.
Thanks for looking at this, but I don't understand why you're confused ;) -- In the situation in the test case, a (<v?i1> = BV <i32>, <i32>, ...) node is having its result promoted. The result of this promotion is (v?i16 = BV <i32>, <i32>, ...). The old code would blindly any_extend the operands to the vector element type of the result (i16 in this case), causing an assertion failure (because we can't any_extend <i32> to <i16>). All I've done in the patch is make sure that the any_extend is legal before we do it. Maybe I should remove mentioning booleans in the comment?
-Hal
>
> Ciao, Duncan.
>
> As a result, we cannot blindly assume that we can ANY_EXTEND the
> operands
> > to the result type.
> >
> > Added:
> > llvm/trunk/test/CodeGen/PowerPC/bv-pres-v8i1.ll
> > Modified:
> > llvm/trunk/lib/CodeGen/SelectionDAG/LegalizeIntegerTypes.cpp
> >
> > Modified:
> > llvm/trunk/lib/CodeGen/SelectionDAG/LegalizeIntegerTypes.cpp
> > URL:
> > http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/SelectionDAG/LegalizeIntegerTypes.cpp?rev=185794&r1=185793&r2=185794&view=diff
> > ==============================================================================
> > --- llvm/trunk/lib/CodeGen/SelectionDAG/LegalizeIntegerTypes.cpp
> > (original)
> > +++ llvm/trunk/lib/CodeGen/SelectionDAG/LegalizeIntegerTypes.cpp
> > Mon Jul 8 01:16:58 2013
> > @@ -2930,7 +2930,13 @@ SDValue DAGTypeLegalizer::PromoteIntRes_
> > SmallVector<SDValue, 8> Ops;
> > Ops.reserve(NumElems);
> > for (unsigned i = 0; i != NumElems; ++i) {
> > - SDValue Op = DAG.getNode(ISD::ANY_EXTEND, dl, NOutVTElem,
> > N->getOperand(i));
> > + SDValue Op;
> > + // It is possible for the operands to be larger than the
> > result, for example,
> > + // when the operands are promoted booleans and the result was
> > an i1 vector.
> > + if (N->getOperand(i).getValueType().bitsLT(NOutVTElem))
> > + Op = DAG.getNode(ISD::ANY_EXTEND, dl, NOutVTElem,
> > N->getOperand(i));
> > + else
> > + Op = N->getOperand(i);
> > Ops.push_back(Op);
> > }
> >
> >
> > Added: llvm/trunk/test/CodeGen/PowerPC/bv-pres-v8i1.ll
> > URL:
> > http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/PowerPC/bv-pres-v8i1.ll?rev=185794&view=auto
> > ==============================================================================
> > --- llvm/trunk/test/CodeGen/PowerPC/bv-pres-v8i1.ll (added)
> > +++ llvm/trunk/test/CodeGen/PowerPC/bv-pres-v8i1.ll Mon Jul 8
> > 01:16:58 2013
> > @@ -0,0 +1,39 @@
> > +; RUN: llc -mtriple=powerpc64-unknown-linux-gnu -mcpu=pwr7 < %s
> > +target triple = "powerpc64-unknown-linux-gnu"
> > +
> > +define void @autogen_SD70() {
> > +BB:
> > + br label %CF78
> > +
> > +CF78: ; preds = %CF87,
> > %CF78, %BB
> > + br i1 undef, label %CF78, label %CF87
> > +
> > +CF87: ; preds = %CF78
> > + %Cmp19 = icmp sge <8 x i1> zeroinitializer, zeroinitializer
> > + %Cmp26 = icmp slt i32 -1, undef
> > + br i1 %Cmp26, label %CF78, label %CF79
> > +
> > +CF79: ; preds = %CF79,
> > %CF87
> > + br i1 undef, label %CF79, label %CF82
> > +
> > +CF82: ; preds = %CF82,
> > %CF79
> > + br i1 undef, label %CF82, label %CF84
> > +
> > +CF84: ; preds = %CF82
> > + br label %CF
> > +
> > +CF: ; preds = %CF88,
> > %CF, %CF84
> > + br i1 undef, label %CF, label %CF85
> > +
> > +CF85: ; preds = %CF85,
> > %CF
> > + %I52 = insertelement <8 x i1> %Cmp19, i1 %Cmp26, i32 6
> > + %Cmp61 = icmp ult i32 477567, undef
> > + br i1 %Cmp61, label %CF85, label %CF88
> > +
> > +CF88: ; preds = %CF85
> > + %E63 = extractelement <8 x i1> %I52, i32 5
> > + br i1 %E63, label %CF, label %CF80
> > +
> > +CF80: ; preds = %CF80,
> > %CF88
> > + br label %CF80
> > +}
> >
> >
> > _______________________________________________
> > 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
>
--
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory
More information about the llvm-commits
mailing list