On Wed, 16 Oct 2024, Robin Dapp wrote:
> > Interesting - this is bleh | bswap (..), right, so having
> > bla1 | (bleh | bla2) fails to recognize bla1 | bla2 as bswap.
>
> Yes, exactly.
>
> > I'd expect this kind of pattern to fail bswap detection easily
> > if you mangle it a bit. So possibly b
> Interesting - this is bleh | bswap (..), right, so having
> bla1 | (bleh | bla2) fails to recognize bla1 | bla2 as bswap.
Yes, exactly.
> I'd expect this kind of pattern to fail bswap detection easily
> if you mangle it a bit. So possibly bswap detection should learn
> to better pick the "piec
> Hmm, reassoc isn't supposed to apply width > 1 before vectorization;
> IIRC I "fixed" that at some point, but this is what I see:
>
> # sum_126 = PHI
> ...
> _23 = *pix_134;
> _24 = (unsigned int) _23;
> _31 = MEM[(uint8_t *)pix_134 + 1B];
> _32 = (unsigned int) _31;
> _118 = _24 +
On Wed, 16 Oct 2024, Robin Dapp wrote:
> Hi,
>
> this is probably rather an RFC than a patch as I'm not sure whether
> reassoc is the right place to fix it. On top, the heuristic might
> be a bit "ad-hoc". Maybe we can also work around it in the vectorizer?
>
> The following function is vector
Hi,
this is probably rather an RFC than a patch as I'm not sure whether
reassoc is the right place to fix it. On top, the heuristic might
be a bit "ad-hoc". Maybe we can also work around it in the vectorizer?
The following function is vectorized in a very inefficient way because we
construct ve
