https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69526
--- Comment #25 from rdapp at linux dot vnet.ibm.com ---
Created attachment 38875
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38875&action=edit
Updated patch and test, math.pd/VRP
Some cleanups and fixes, the patch can now handle more ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69526
--- Comment #24 from rdapp at linux dot vnet.ibm.com ---
Created attachment 38775
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38775&action=edit
Updated patch and test, match.pd/VRP
(In reply to amker from comment #23)
> Hmm, not sure if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69526
--- Comment #23 from amker at gcc dot gnu.org ---
(In reply to rdapp from comment #19)
> (In reply to rguent...@suse.de from comment #18)
> 2.
> Is there an idiomatic/correct way to check a VR_RANGE for overflow? Does it
> suffice to check if the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69526
--- Comment #22 from amker at gcc dot gnu.org ---
(In reply to rdapp from comment #21)
> (In reply to amker from comment #20)
> > IIUC we can simply handle signed/unsigned type differently. Given a has
> > int/uint type.
> > For unsigned case: (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69526
rdapp at linux dot vnet.ibm.com changed:
What|Removed |Added
Version|6.0 |unknown
--- Comment #21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69526
--- Comment #20 from amker at gcc dot gnu.org ---
(In reply to rdapp from comment #19)
> (In reply to rguent...@suse.de from comment #18)
> >
>
> The match.pd patch is slowly assuming shape... Two things however I'm still
> unsure about:
>
> 1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69526
--- Comment #19 from rdapp at linux dot vnet.ibm.com ---
(In reply to rguent...@suse.de from comment #18)
>
The match.pd patch is slowly assuming shape... Two things however I'm still
unsure about:
1.
An existing rule in match.pd checks for over
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69526
--- Comment #18 from rguenther at suse dot de ---
On Tue, 7 Jun 2016, rdapp at linux dot vnet.ibm.com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69526
>
> --- Comment #15 from rdapp at linux dot vnet.ibm.com ---
> Thanks for the sugg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69526
--- Comment #17 from rdapp at linux dot vnet.ibm.com ---
(In reply to Marc Glisse from comment #16)
> (In reply to rdapp from comment #15)
> > Is there a simple method to access @inner when
> > capturing
> > (outer_op (convert (inner_op SSA_NAME@0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69526
--- Comment #16 from Marc Glisse ---
(In reply to rdapp from comment #15)
> Is there a simple method to access @inner when
> capturing
> (outer_op (convert (inner_op SSA_NAME@0 INTEGER_CST@1)) INTEGER_CST@2))
>^---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69526
--- Comment #15 from rdapp at linux dot vnet.ibm.com ---
Thanks for the suggestions. The omission of the inner op was actually more or
less on purpose as I intended to capture the
(convert @inner)
in order to access @inner's value range as a whole
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69526
--- Comment #14 from rguenther at suse dot de ---
On Fri, 20 May 2016, rdapp at linux dot vnet.ibm.com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69526
>
> --- Comment #13 from rdapp at linux dot vnet.ibm.com ---
> Created attachment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69526
--- Comment #13 from rdapp at linux dot vnet.ibm.com ---
Created attachment 38535
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38535&action=edit
VRP/match.pd patch
Found some time again and hacked together a fix for match.pd and VRP. The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69526
--- Comment #12 from Richard Biener ---
So, we don't optimize at -O2
long foo (int a)
{
return (long)(a + 1) - 1;
}
Note that (T)(A +- CST1) +- CST2 -> (T)A +- CST3 thus the combined
addition in general needs to be done in the larger type _un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69526
--- Comment #11 from Richard Biener ---
(In reply to rdapp from comment #10)
> Created attachment 38144 [details]
> Tentative patch for VRP and loop-doloop
>
> Meanwhile I found the time to implement a pattern for VRP which seems to do
> the job
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69526
--- Comment #10 from rdapp at linux dot vnet.ibm.com ---
Created attachment 38144
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38144&action=edit
Tentative patch for VRP and loop-doloop
Meanwhile I found the time to implement a pattern for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69526
--- Comment #9 from Richard Biener ---
Note that VRP figures out that
_15 = n_18 + 4294967295;
Found new range for _15: [0, 4294967294]
(so no underflow)
_2 = (sizetype) _15;
Found new range for _2: [0, 4294967294]
_1 = _2 + 1;
Found new range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69526
--- Comment #8 from amker at gcc dot gnu.org ---
(In reply to rdapp from comment #7)
> (In reply to amker from comment #6)
>
> > It comes from loop niter analysis, as in may_eliminate_iv, we have:
> >
> > (gdb) call debug_generic_expr(desc->nite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69526
--- Comment #7 from rdapp at linux dot vnet.ibm.com ---
(In reply to amker from comment #6)
> It comes from loop niter analysis, as in may_eliminate_iv, we have:
>
> (gdb) call debug_generic_expr(desc->niter)
> n_5(D) + 4294967295
and this is c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69526
--- Comment #6 from amker at gcc dot gnu.org ---
(In reply to rdapp from comment #5)
> I still don't quite get why the "n - 1" is needed. Do we need it to possibly
> have an exit condition like
>
> if (i != n-1) or
> if (i <= n-1)?
>
> Am I m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69526
--- Comment #5 from rdapp at linux dot vnet.ibm.com ---
I still don't quite get why the "n - 1" is needed. Do we need it to possibly
have an exit condition like
if (i != n-1) or
if (i <= n-1)?
Am I missing something really obvious here?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69526
--- Comment #4 from amker at gcc dot gnu.org ---
(In reply to rdapp from comment #2)
> Ok, that's sensible but why is the - 1 necessary in the first place?
>
> n_5 - 1 can only underflow if n_5 == 0 which is checked by
>
> testl %edx, %edx
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69526
--- Comment #3 from amker at gcc dot gnu.org ---
(In reply to rdapp from comment #2)
> Ok, that's sensible but why is the - 1 necessary in the first place?
>
> n_5 - 1 can only underflow if n_5 == 0 which is checked by
>
> testl %edx, %edx
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69526
--- Comment #2 from rdapp at linux dot vnet.ibm.com ---
Ok, that's sensible but why is the - 1 necessary in the first place?
n_5 - 1 can only underflow if n_5 == 0 which is checked by
testl %edx, %edx
before. This is in a previous basic block,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69526
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Status|
25 matches
Mail list logo
