[llvm-commits] Fix the AND dag node folding

[Silviu Baranga]

Hi Eli,

> +          Constant &=
> SplatValue.lshr(i*BitWidthSrc).zextOrTrunc(BitWidthSrc);
> 
> I don't follow what you're doing here: the splat value is computed
> relative to the BUILD_VECTOR, and is completely unrelated to the width
> of the original load.
Good catch. There is a bug in that statement, and it should have been:
"Constant &= SplatValue.lshr(i*BitWidthDst).zextOrTrunc(BitWidthSrc);"
to be correct.

However, it turns out that it doesn't matter if we use the load type
size there or not since we will zextOrTrunc the constant to the
load type lane size anyway further down the code path. Therefore, 
I've removed any references to the load node from the changes.

I've attached an updated patch.

Thanks,
Silviu

> -----Original Message-----
> From: Eli Friedman [mailto:eli.friedman at gmail.com]
> Sent: 29 August 2012 21:40
> To: Silviu Baranga
> Cc: llvm-commits at cs.uiuc.edu
> Subject: Re: [llvm-commits] Fix the AND dag node folding
> 
> On Thu, Aug 23, 2012 at 8:54 AM, Silviu Baranga <silbar01 at arm.com>
> wrote:
> > Hi,
> >
> > There are currently some bugs in implementation of the folding of AND
> nodes
> > in the DAG combiner which cause the DAG combiner to miss some folding
> > opportunities when trying to fold "(and (load ([non_ext|zero_ext]
> V)))" on
> > vector types.
> >
> > The issues are:
> > 1. The VT type was not corresponding to the input vector type when
> the LOAD
> >    dag node was the operand of the LOAD node.
> 
> +          Constant &=
> SplatValue.lshr(i*BitWidthSrc).zextOrTrunc(BitWidthSrc);
> 
> I don't follow what you're doing here: the splat value is computed
> relative to the BUILD_VECTOR, and is completely unrelated to the width
> of the original load.
> 
> > 2. The isConstantSplat method does not always return a mask with
> values for
> >    all the vector lanes (it reduces this mask when possible).
> 
> +        for (unsigned i = 0, n = SplatBitSize/BitWidthDst; i < n; ++i)
> 
> This part looks fine.
> 
> -Eli
-------------- next part --------------
A non-text attachment was scrubbed...
Name: zext.diff
Type: application/octet-stream
Size: 1224 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120830/868bc586/attachment.obj>