On 22/06/15 16:36, Richard Biener wrote:
On Thu, 18 Jun 2015, Tom de Vries wrote:
On 13/06/15 16:24, Tom de Vries wrote:
Hi,
this patch allows try_transform_to_exit_first_loop_alt to succeed when
handling cases where the expression representing the number of
iterations contains a cast.
Currently, transform_to_exit_first_loop_alt testcase
gfortran/parloops-exit-first-loop-alt.f95 will fail.
The nit is _19, which is defined as follows:
...
_20 = _6 + -1;
_19 = (unsigned int) _20;
...
And transform_to_exit_first_loop_alt currently only handles nits with
defining stmt 'nit = x - 1', for which it finds alt_bound 'x'.
The patch:
- uses try_get_loop_niter to get nit as a nested tree expression
'(unsigned int) (_6 + -1)'
- strips the outer nops (assuming no change in value)
- uses '(unsigned int)_6' as the alt_bound, and
- gimplifies the expression.
Bootstrapped and reg-tested on x86_64.
Cleaned up whitespace in testcases.
Committed to gomp-4_0-branch as atttached.
OK for trunk?
I assume the above also handles the reverse, (int) (_6 + -1)?
AFAIU, niter.niter is always unsigned.
In this case what happens if _6 == INT_MAX + 1? nit is INT_MAX
but (int) _6 is INT_MIN.
Likewise what happens if _6 + -1 under-/overflows?
While playing around with underflow/overflow cases, I ran into PR66652,
which reproduces on trunk.
I've submitted for trunk:
- https://gcc.gnu.org/ml/gcc-patches/2015-06/msg02084.html , which
fixes PR66652, and should handle all overflow concerns.
- https://gcc.gnu.org/ml/gcc-patches/2015-06/msg02085.html , which deals
with the case that nit is not defined by assignment nit = n - 1, in
other words, with the case that this patch is trying to address.
I'll revert this patch on gomp-4_0-branch, and commit these patches
instead (in addition to
https://gcc.gnu.org/ml/gcc-patches/2015-06/msg01768.html, which fixes
low iteration count reduction loops handled by
transform_to_exit_first_loop_alt).
Thanks,
- Tom
