This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][vectorizer][2/2] Hook up mult synthesis logic into vectorisation of mult-by-constant
- From: Marc Glisse <marc dot glisse at inria dot fr>
- To: Kyrill Tkachov <kyrylo dot tkachov at foss dot arm dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, Richard Biener <rguenther at suse dot de>
- Date: Wed, 15 Jun 2016 23:53:23 +0200 (CEST)
- Subject: Re: [PATCH][vectorizer][2/2] Hook up mult synthesis logic into vectorisation of mult-by-constant
- Authentication-results: sourceware.org; auth=none
- References: <5761570E dot 2020906 at foss dot arm dot com>
On Wed, 15 Jun 2016, Kyrill Tkachov wrote:
This is a respin of https://gcc.gnu.org/ml/gcc-patches/2016-06/msg00952.html
following feedback.
I've changed the code to cast the operand to an unsigned type before applying
the multiplication algorithm
and cast it back to the signed type at the end.
Whether to perform the cast is now determined by the function
cast_mult_synth_to_unsigned in which I've implemented
the cases that Marc mentioned in [1]. Please do let me know
if there are any other cases that need to be handled.
Ah, I never meant those cases as an exhaustive list, I was just looking
for examples showing that the transformation was unsafe, and those 2 came
to mind:
- x*15 -> x*16-x the second one can overflow even when the first one
doesn't.
- x*-2 -> -(x*2) can overflow when the result is INT_MIN (maybe that's
redundant with the negate_variant check?)
On the other hand, as long as we remain in the 'positive' operations,
turning x*3 to x<<1+x seems perfectly safe. And even x*30 to (x*16-x)*2
cannot cause spurious overflows. But I didn't look at the algorithm
closely enough to characterize the safe cases. Now if you have done it,
that's good :-) Otherwise, we might want to err on the side of caution.
--
Marc Glisse