<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/4.2.2">
</HEAD>
<BODY>
Not sure, it's answer but vector promotion seems skipped on non-byte-sized elements.<BR>
<BR>
<PRE>
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());

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

  for (; I != E; ++I) {
    if (!I->U)
</PRE>
<BR>
Chandler, could you confirm that?<BR>
<BR>
Yours<BR>
- Michael<BR>
<BR>
On Wed, 2013-03-06 at 18:41 -0600, Hal Finkel wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
----- Original Message -----
> From: "Nadav Rotem" <<A HREF="mailto:nrotem@apple.com">nrotem@apple.com</A>>
> To: "Michael Liao" <<A HREF="mailto:michael.liao@intel.com">michael.liao@intel.com</A>>
> Cc: "Hal Finkel" <<A HREF="mailto:hfinkel@anl.gov">hfinkel@anl.gov</A>>, "Duncan Sands" <<A HREF="mailto:baldrick@free.fr">baldrick@free.fr</A>>, <A HREF="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</A>
> 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 < <A HREF="mailto:michael.liao@intel.com">michael.liao@intel.com</A> >
> wrote:



> ping again. - michael

> On Fri, 2013-03-01 at 00:35 -0600, Hal Finkel wrote:


> ----- Original Message -----


> From: "Michael Liao" < <A HREF="mailto:michael.liao@intel.com">michael.liao@intel.com</A> >
> To: <A HREF="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</A>
> 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.)

> +@X = global <4 x i1> <i1 0, i1 1, i1 2, i1 3>
> +@Y = global <4 x i3> <i3 0, i3 1, i3 2, i3 3>
> +@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
> <A HREF="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</A>
> <A HREF="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</A>


> <0001-Fix-PR15131-part-of-PR1784.patch>

</PRE>
</BLOCKQUOTE>
<BR>
</BODY>
</HTML>