From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11479 invoked by alias); 19 Jan 2015 13:10:32 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 11372 invoked by uid 48); 19 Jan 2015 13:10:26 -0000 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/62630] [5 regression] gcc.dg/graphite/vect-pr43423.c FAILs Date: Mon, 19 Jan 2015 13:10:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 5.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 5.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: keywords cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-01/txt/msg01832.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62630 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |missed-optimization CC| |grosser at gcc dot gnu.org --- Comment #4 from Richard Biener --- 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 : _46 = (signed long) mid_6(D); ... : graphite_IV.5_50 = MAX_EXPR <_46, 0>; _51 = (signed long) n_5(D); _52 = _51 + -1; : # graphite_IV.5_53 = PHI _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 ; else goto ; : goto ; (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?