public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.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 [thread overview] Message-ID: <bug-62630-4-4UHui2IPKk@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-62630-4@http.gcc.gnu.org/bugzilla/> 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?
next prev parent reply other threads:[~2015-01-19 13:10 UTC|newest] Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-09-01 13:21 [Bug tree-optimization/62630] New: " ro at gcc dot gnu.org 2014-09-01 13:24 ` [Bug tree-optimization/62630] " ro at gcc dot gnu.org 2014-09-01 13:26 ` ro at gcc dot gnu.org 2014-09-01 13:32 ` ktkachov at gcc dot gnu.org 2014-11-24 13:13 ` rguenth at gcc dot gnu.org 2015-01-19 13:10 ` rguenth at gcc dot gnu.org [this message] 2015-02-12 13:17 ` jakub at gcc dot gnu.org 2015-02-17 10:49 ` rguenth at gcc dot gnu.org 2015-02-17 20:12 ` mircea.namolaru at inria dot fr 2015-02-18 11:23 ` rguenth at gcc dot gnu.org 2015-02-18 11:34 ` rguenth at gcc dot gnu.org 2015-02-18 11:57 ` mircea.namolaru at inria dot fr 2015-02-18 13:03 ` rguenth at gcc dot gnu.org 2015-02-18 15:06 ` rguenth at gcc dot gnu.org 2015-02-18 15:25 ` rguenth at gcc dot gnu.org 2015-02-18 23:34 ` mircea.namolaru at inria dot fr 2015-02-19 10:19 ` rguenth at gcc dot gnu.org 2015-02-20 0:45 ` mircea.namolaru at inria dot fr 2015-02-20 16:46 ` joseph at codesourcery dot com 2015-02-23 18:21 ` mircea.namolaru at inria dot fr 2015-03-09 14:40 ` jakub at gcc dot gnu.org 2015-03-25 13:14 ` [Bug tree-optimization/62630] [5/6 Regression] gcc.dg/graphite/vect-pr43423.c XFAILed rguenth at gcc dot gnu.org 2015-03-25 13:20 ` rguenth at gcc dot gnu.org 2021-05-14 9:47 ` [Bug tree-optimization/62630] [9/10/11/12 " jakub at gcc dot gnu.org 2021-06-01 8:06 ` rguenth at gcc dot gnu.org 2021-09-14 6:24 ` pinskia at gcc dot gnu.org 2022-05-27 9:35 ` [Bug tree-optimization/62630] [10/11/12/13 " rguenth at gcc dot gnu.org 2022-06-28 10:31 ` jakub at gcc dot gnu.org 2023-07-07 10:30 ` [Bug tree-optimization/62630] [11/12/13/14 " rguenth at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-62630-4-4UHui2IPKk@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).