https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62630
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |missed-optimization
CC| |grosser at gcc dot gnu.org
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
7: note: === vect_analyze_data_refs ===
Creating dr for a[_56]
analyze_innermost:
failed: evolution of offset is not affine.
base_address:
offset from base address:
constant offset from base address:
step:
aligned to:
base_object: a
Access function 0: (int) {(unsigned int) graphite_IV.5_50, +, 1}_3;
the graphive IVs are signed long
<bb 8>:
_46 = (signed long) mid_6(D);
...
<bb 9>:
graphite_IV.5_50 = MAX_EXPR <_46, 0>;
_51 = (signed long) n_5(D);
_52 = _51 + -1;
<bb 10>:
# graphite_IV.5_53 = PHI <graphite_IV.5_50(9), graphite_IV.5_54(11)>
_56 = (int) graphite_IV.5_53;
_55 = a[_56];
_57 = c[_56];
_58 = _55 + _57;
_64 = (int) graphite_IV.5_53;
a[_64] = _58;
graphite_IV.5_54 = graphite_IV.5_53 + 1;
if (graphite_IV.5_53 < _52)
goto <bb 11>;
else
goto <bb 13>;
<bb 11>:
goto <bb 10>;
(instantiate_scev
(instantiate_below = 9)
(evolution_loop = 3)
(chrec = (ssizetype) (int) {(unsigned int) graphite_IV.5_50, +, 1}_3)
(res = (ssizetype) (int) {(unsigned int) graphite_IV.5_50, +, 1}_3))
so it appears to SCEV that the evolution may wrap.
With GCC 4.9 we choose signed int as GRAPHITE IV.
Looks like the IV type is statically determined by
graphite_expression_type_precision as
/* We always try to use signed 128 bit types, but fall back to smaller types
in case a platform does not provide types of these sizes. In the future we
should use isl to derive the optimal type for each subexpression. */
static int max_mode_int_precision =
GET_MODE_PRECISION (mode_for_size (MAX_FIXED_MODE_SIZE, MODE_INT, 0));
static int graphite_expression_type_precision = 128 <= max_mode_int_precision ?
128 : max_mode_int_precision;
Not sure how this doesn't end up with __int128_t on x86_64, but ...
It's obviously a bad choice to use __int128_t (or even signed long) everywhere.
Let's XFAIL this testcase if nobody fixes the underlying issue. What does it
take to "use ISL to derive the optimal type for each subexpression"? Is
that even possible?
