On Thu, Jul 20, 2017 at 11:39 AM, Alexander Monakov wrote:
> On Thu, 20 Jul 2017, Richard Biener wrote:
>> >> So for saturating types isn't the issue when @1 and @2 have opposite
>> >> sign and the inner multiply would have saturated?
>> >
>> > No, I think the only special case is @1 == @2 == -1,
On Thu, 20 Jul 2017, Richard Biener wrote:
> >> So for saturating types isn't the issue when @1 and @2 have opposite
> >> sign and the inner multiply would have saturated?
> >
> > No, I think the only special case is @1 == @2 == -1, otherwise either @2 is
> > 0 or 1, or @1 * @2 is larger in magnitu
On Wed, Jul 19, 2017 at 4:39 PM, Alexander Monakov wrote:
> On Wed, 19 Jul 2017, Richard Biener wrote:
>> >> --- a/gcc/match.pd
>> >> +++ b/gcc/match.pd
>> >> @@ -283,6 +283,20 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
>> >> || mul != wi::min_value (TYPE_PRECISION (type), SIGNED))
>> >>
On Wed, 19 Jul 2017, Richard Biener wrote:
> >> --- a/gcc/match.pd
> >> +++ b/gcc/match.pd
> >> @@ -283,6 +283,20 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
> >> || mul != wi::min_value (TYPE_PRECISION (type), SIGNED))
> >> { build_zero_cst (type); })
> >>
> >> +/* Combine successiv
On Wed, Jul 19, 2017 at 1:28 PM, Richard Biener
wrote:
> On Tue, Jul 18, 2017 at 7:07 PM, Alexander Monakov wrote:
>> On Mon, 17 Jul 2017, Alexander Monakov wrote:
>>> On Mon, 17 Jul 2017, Marc Glisse wrote:
>>> > > +/* Combine successive multiplications. Similar to above, but handling
>>> > > +
On Tue, Jul 18, 2017 at 7:07 PM, Alexander Monakov wrote:
> On Mon, 17 Jul 2017, Alexander Monakov wrote:
>> On Mon, 17 Jul 2017, Marc Glisse wrote:
>> > > +/* Combine successive multiplications. Similar to above, but handling
>> > > + overflow is different. */
>> > > +(simplify
>> > > + (mult
On Mon, 17 Jul 2017, Alexander Monakov wrote:
> On Mon, 17 Jul 2017, Marc Glisse wrote:
> > > +/* Combine successive multiplications. Similar to above, but handling
> > > + overflow is different. */
> > > +(simplify
> > > + (mult (mult @0 INTEGER_CST@1) INTEGER_CST@2)
> > > + (with {
> > > +
On Fri, Jul 14, 2017 at 7:59 AM, Marc Glisse wrote:
> On Thu, 13 Jul 2017, Alexander Monakov wrote:
>
>> On Thu, 13 Jul 2017, Marc Glisse wrote:
>>>
>>> I notice that we do not turn (X*10)*10 into X*100 in GIMPLE.
>>
>>
>> Sorry, could you clarify what you mean here? I think we certainly do
>> th
On Mon, 17 Jul 2017, Marc Glisse wrote:
> > +/* Combine successive multiplications. Similar to above, but handling
> > + overflow is different. */
> > +(simplify
> > + (mult (mult @0 INTEGER_CST@1) INTEGER_CST@2)
> > + (with {
> > + bool overflow_p;
> > + wide_int mul = wi::mul (@1, @2, TYP
On Sat, 15 Jul 2017, Alexander Monakov wrote:
On Thu, 13 Jul 2017, Marc Glisse wrote:
X*big*big where abs(big*big)>abs(INT_MIN) can be optimized to 0
I'm not sure that would be a win, eliminating X prevents the compiler from
deducing that X must be zero (if overflow invokes undefined behavior
On Thu, 13 Jul 2017, Marc Glisse wrote:
> X*big*big where abs(big*big)>abs(INT_MIN) can be optimized to 0
I'm not sure that would be a win, eliminating X prevents the compiler from
deducing that X must be zero (if overflow invokes undefined behavior).
> the only hard case is when the product of t
On Thu, 13 Jul 2017, Marc Glisse wrote:
> I notice that we do not turn (X*10)*10 into X*100 in GIMPLE [...]
I've completely missed that. Posting another patch to address that.
> Relying on inner expressions being folded can be slightly dangerous,
> especially for generic IIRC. It seems easy enou
On Thu, 13 Jul 2017, Alexander Monakov wrote:
On Thu, 13 Jul 2017, Marc Glisse wrote:
I notice that we do not turn (X*10)*10 into X*100 in GIMPLE.
Sorry, could you clarify what you mean here? I think we certainly do that,
just not via match.pd, but in 'associate:' case of fold_binary_loc.
On Thu, 13 Jul 2017, Marc Glisse wrote:
> I notice that we do not turn (X*10)*10 into X*100 in GIMPLE.
Sorry, could you clarify what you mean here? I think we certainly do that,
just not via match.pd, but in 'associate:' case of fold_binary_loc.
> Relying on inner expressions being folded can be
On Thu, 13 Jul 2017, Alexander Monakov wrote:
This is a followup to https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01545.html
Recently due to a fix for PR 80800 GCC has lost the ability to reassociate
signed multiplications chains to go from 'X * CST1 * Y * CST2'
to 'X * Y * (CST1 * CST2)'. The
Hi,
This is a followup to https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01545.html
Recently due to a fix for PR 80800 GCC has lost the ability to reassociate
signed multiplications chains to go from 'X * CST1 * Y * CST2'
to 'X * Y * (CST1 * CST2)'. The fix to that PR prevents extract_muldiv from
16 matches
Mail list logo
