[PATCH] Fix PR15131

[Michael Liao]

Not sure, it's answer but vector promotion seems skipped on
non-byte-sized elements.


static bool isVectorPromotionViable(const DataLayout &TD,
                                    Type *AllocaTy,
                                    AllocaPartitioning &P,
                                    uint64_t PartitionBeginOffset,
                                    uint64_t PartitionEndOffset,
                                    AllocaPartitioning::const_use_iterator I,
                                    AllocaPartitioning::const_use_iterator E) {
  VectorType *Ty = dyn_cast<VectorType>(AllocaTy);
  if (!Ty)
    return false;

  uint64_t ElementSize = TD.getTypeSizeInBits(Ty->getScalarType());

  // While the definition of LLVM vectors is bitpacked, we don't support sizes
  // that aren't byte sized.
  if (ElementSize % 8)
    return false;
  assert((TD.getTypeSizeInBits(Ty) % 8) == 0 &&
         "vector size not a multiple of element size?");
  ElementSize /= 8;

  for (; I != E; ++I) {
    if (!I->U)


Chandler, could you confirm that?

Yours
- Michael

On Wed, 2013-03-06 at 18:41 -0600, Hal Finkel wrote:

> ----- Original Message -----
> > From: "Nadav Rotem" <nrotem at apple.com>
> > To: "Michael Liao" <michael.liao at intel.com>
> > Cc: "Hal Finkel" <hfinkel at anl.gov>, "Duncan Sands" <baldrick at free.fr>, llvm-commits at cs.uiuc.edu
> > Sent: Wednesday, March 6, 2013 6:33:45 PM
> > Subject: Re: [PATCH] Fix PR15131
> > 
> > I think that SROA assumes that vector operands are not bitpacked. Can
> > you check if we can SROA the packed vectors ?
> 
> [I'd think that Chandler would be the best person to comment on this].
> 
>  -Hal
> 
> > 
> > 
> > Thanks,
> > Nadav
> > 
> > 
> > 
> > On Mar 6, 2013, at 9:35 AM, Michael Liao < michael.liao at intel.com >
> > wrote:
> > 
> > 
> > 
> > ping again. - michael
> > 
> > On Fri, 2013-03-01 at 00:35 -0600, Hal Finkel wrote:
> > 
> > 
> > ----- Original Message -----
> > 
> > 
> > From: "Michael Liao" < michael.liao at intel.com >
> > To: llvm-commits at cs.uiuc.edu
> > Sent: Thursday, February 28, 2013 11:13:30 PM
> > Subject: [PATCH] Fix PR15131
> > 
> > Hi All,
> > 
> > The attached patch fixes PR15131 which is caused by mismatching
> > between
> > global vector constant emission logic and vector in-memory
> > representation (bitpacked now.)
> > 
> > + at X = global <4 x i1> <i1 0, i1 1, i1 2, i1 3>
> > + at Y = global <4 x i3> <i3 0, i3 1, i3 2, i3 3>
> > + at Z = global <5 x i30> <i30 0, i30 1, i30 2, i30 3, i30 4>
> > +
> > +; CHECK: byte 10
> > +; CHECK: short 1672
> > +; CHECK: quad 2305843010287435776
> > +; CHECK: quad 288230376353038336
> > +; CHECK: quad 0
> > +; CHECK: quad 0
> > 
> > Is this really the behavior that we want, or do we only want to
> > bitpack i1 vectors? Or vectors with an element size less than 1
> > byte? I could be wrong, but I think that at least your last example
> > (<5 x i30>) will break currently-working code that operates on
> > vectors of arbitrarily-sized integers. Duncan?
> > 
> > -Hal
> > 
> > 
> > 
> > 
> > Thanks for review
> > - Michael
> > 
> > 
> > _______________________________________________
> > llvm-commits mailing list
> > llvm-commits at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> > 
> > 
> > <0001-Fix-PR15131-part-of-PR1784.patch>
> > 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130306/33672064/attachment.html>