On Mon, 26 Jul 2021, Roger Sayle wrote:
The one aspect that's a little odd is that each transform is paired with
a convert@1 variant, using the efficient match machinery to expose any
zero extension to fold-const.c's tree_nonzero_bits functionality.
Copying the first transform for context
+(
The easiest way to motivate these additions to match.pd is with the
following example:
unsigned int foo(unsigned char i) {
return i | (i<<8) | (i<<16) | (i<<24);
}
which mainline with -O2 on x86_64 currently generates:
foo:movzbl %dil, %edi
movl%edi, %eax
movl%edi,
On Thu, 15 Oct 2020, guojiufu wrote:
> Hi,
>
> I just had a check on below patch for PR66552.
> https://gcc.gnu.org/pipermail/gcc-patches/2020-February/540930.html
> It seems this patch works fine now. This patch fixes PR66552 which
> request to optimizes (x shift (n mod C)) to
> (x shift (n bit_
Hi!
On Thu, Oct 15, 2020 at 03:52:01PM +0800, guojiufu wrote:
> I just had a check on below patch for PR66552.
> https://gcc.gnu.org/pipermail/gcc-patches/2020-February/540930.html
> It seems this patch works fine now. This patch fixes PR66552 which
> request to optimizes (x shift (n mod C)) to
>
Hi,
I just had a check on below patch for PR66552.
https://gcc.gnu.org/pipermail/gcc-patches/2020-February/540930.html
It seems this patch works fine now. This patch fixes PR66552 which
request to optimizes (x shift (n mod C)) to
(x shift (n bit_and (C - 1))) when C is a constant and power of two.
On Tue, 7 May 2019, Jakub Jelinek wrote:
> On Tue, May 07, 2019 at 01:50:23PM +0200, Marc Glisse wrote:
> > > And actually it seems that we could optimize the plus1 == plus2 cases
> > > even if HONOR_SIGN_DEPENDENT_ROUNDING (type), because even in fesetenv
> > > (FE_DOWNWARD) mode the testcase pri
On Tue, May 07, 2019 at 01:50:23PM +0200, Marc Glisse wrote:
> > And actually it seems that we could optimize the plus1 == plus2 cases
> > even if HONOR_SIGN_DEPENDENT_ROUNDING (type), because even in fesetenv
> > (FE_DOWNWARD) mode the testcase prints the first two (in all other modes all
> > 4).
On Tue, 7 May 2019, Jakub Jelinek wrote:
On Tue, May 07, 2019 at 09:55:21AM +0200, Jakub Jelinek wrote:
On Tue, May 07, 2019 at 09:48:13AM +0200, Richard Biener wrote:
Will leave the "correctness check" for other folks
but the above is
BTW, as I wanted to be sure about the correctness, I wro
On Tue, May 07, 2019 at 09:55:21AM +0200, Jakub Jelinek wrote:
> On Tue, May 07, 2019 at 09:48:13AM +0200, Richard Biener wrote:
> > Will leave the "correctness check" for other folks
> > but the above is
BTW, as I wanted to be sure about the correctness, I wrote a simple program
(below).
And actu
On Tue, May 07, 2019 at 09:48:13AM +0200, Richard Biener wrote:
> Will leave the "correctness check" for other folks but the above is
> better written as
>
> + (outer_op (inner_op @0 REAL_CST@1) REAL_CST@2)
> +(if (real_zerop (@1)
> + && real_zerop (@2)
>
> because that gets code-ge
On Tue, 7 May 2019, Jakub Jelinek wrote:
> Hi!
>
> fold_real_zero_addition_p will fold x + (-0.0) or x - 0.0 to x
> when not -frounding-math, but not the rest of the options when
> -fsigned-zeros, and not when -fsignaling-nans.
> If we have (x + 0.0) + 0.0, we can fold that to just x + 0.0 even
>
Hi!
fold_real_zero_addition_p will fold x + (-0.0) or x - 0.0 to x
when not -frounding-math, but not the rest of the options when
-fsigned-zeros, and not when -fsignaling-nans.
If we have (x + 0.0) + 0.0, we can fold that to just x + 0.0 even
when honoring signed zeros, and IMNSHO even when honori
On June 10, 2016 6:15:25 PM GMT+02:00, Jason Merrill wrote:
>On Fri, Jun 10, 2016 at 3:11 AM, Richard Biener
>wrote:
>> On Thu, 9 Jun 2016, Jason Merrill wrote:
>>
>>> On Thu, Jun 9, 2016 at 3:39 AM, Richard Biener
>wrote:
>>> > On Thu, 9 Jun 2016, Jakub Jelinek wrote:
>>> >
>>> >> On Thu, Jun 0
On Fri, Jun 10, 2016 at 3:11 AM, Richard Biener wrote:
> On Thu, 9 Jun 2016, Jason Merrill wrote:
>
>> On Thu, Jun 9, 2016 at 3:39 AM, Richard Biener wrote:
>> > On Thu, 9 Jun 2016, Jakub Jelinek wrote:
>> >
>> >> On Thu, Jun 09, 2016 at 08:50:15AM +0200, Richard Biener wrote:
>> >> > On Wed, 8 J
On Thu, 9 Jun 2016, Jason Merrill wrote:
> On Thu, Jun 9, 2016 at 3:39 AM, Richard Biener wrote:
> > On Thu, 9 Jun 2016, Jakub Jelinek wrote:
> >
> >> On Thu, Jun 09, 2016 at 08:50:15AM +0200, Richard Biener wrote:
> >> > On Wed, 8 Jun 2016, Jason Merrill wrote:
> >> >
> >> > > On Wed, Jun 8, 201
On Thu, Jun 9, 2016 at 3:39 AM, Richard Biener wrote:
> On Thu, 9 Jun 2016, Jakub Jelinek wrote:
>
>> On Thu, Jun 09, 2016 at 08:50:15AM +0200, Richard Biener wrote:
>> > On Wed, 8 Jun 2016, Jason Merrill wrote:
>> >
>> > > On Wed, Jun 8, 2016 at 11:16 AM, Marc Glisse
>> > > wrote:
>> > > > On W
On Thu, 9 Jun 2016, Jakub Jelinek wrote:
> On Thu, Jun 09, 2016 at 08:50:15AM +0200, Richard Biener wrote:
> > On Wed, 8 Jun 2016, Jason Merrill wrote:
> >
> > > On Wed, Jun 8, 2016 at 11:16 AM, Marc Glisse wrote:
> > > > On Wed, 8 Jun 2016, Richard Biener wrote:
> > > >
> > > >> The following w
On Thu, Jun 09, 2016 at 08:50:15AM +0200, Richard Biener wrote:
> On Wed, 8 Jun 2016, Jason Merrill wrote:
>
> > On Wed, Jun 8, 2016 at 11:16 AM, Marc Glisse wrote:
> > > On Wed, 8 Jun 2016, Richard Biener wrote:
> > >
> > >> The following works around PR70992 but the issue came up repeatedly
> >
On Thu, 9 Jun 2016, Marc Glisse wrote:
> On Wed, 8 Jun 2016, Jakub Jelinek wrote:
>
> > On Wed, Jun 08, 2016 at 01:43:56PM -0400, Jason Merrill wrote:
> > > > A few random ideas I was considering:
> > > > * restrict it to GIMPLE, so we can't have a regression in the
> > > > front-ends.
> > > > *
On Wed, 8 Jun 2016, Jason Merrill wrote:
> On Wed, Jun 8, 2016 at 11:16 AM, Marc Glisse wrote:
> > On Wed, 8 Jun 2016, Richard Biener wrote:
> >
> >> The following works around PR70992 but the issue came up repeatedly
> >> that we are not very consistent in preserving the undefined behavior
> >>
On Wed, 8 Jun 2016, Jakub Jelinek wrote:
On Wed, Jun 08, 2016 at 01:43:56PM -0400, Jason Merrill wrote:
A few random ideas I was considering:
* restrict it to GIMPLE, so we can't have a regression in the front-ends.
* fold x/0 to 0 with TREE_OVERFLOW set, to tell the front-end that something
is
On Wed, Jun 08, 2016 at 01:43:56PM -0400, Jason Merrill wrote:
> > A few random ideas I was considering:
> > * restrict it to GIMPLE, so we can't have a regression in the front-ends.
> > * fold x/0 to 0 with TREE_OVERFLOW set, to tell the front-end that something
> > is going on.
> > * fold to (x/y
On Wed, Jun 8, 2016 at 11:16 AM, Marc Glisse wrote:
> On Wed, 8 Jun 2016, Richard Biener wrote:
>
>> The following works around PR70992 but the issue came up repeatedly
>> that we are not very consistent in preserving the undefined behavior
>> of division or modulo by zero. Ok - the only inconsis
On Wed, 8 Jun 2016, Richard Biener wrote:
The following works around PR70992 but the issue came up repeatedly
that we are not very consistent in preserving the undefined behavior
of division or modulo by zero. Ok - the only inconsistency is
that we fold 0 % x to 0 but not 0 % 0 (with literal ze
The following works around PR70992 but the issue came up repeatedly
that we are not very consistent in preserving the undefined behavior
of division or modulo by zero. Ok - the only inconsistency is
that we fold 0 % x to 0 but not 0 % 0 (with literal zero).
After folding is now no longer done ea
This makes us fold (X * 8) & 5 to zero and (X * 6) & 5 to (X * 6) & 4.
It amends the fix for PR52134 in that I noticed we fail to do some
simplifications on size expressions (later on SSA, CCP does the above
transform, though not (yet) changing of the constant).
Bootstrap and regtest ongoing on x
26 matches
Mail list logo
