public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/111820] [13/14 Regression] Compiler time hog in the vectorizer with `-O3 -fno-tree-vrp` Date: Tue, 17 Oct 2023 07:16:18 +0000 [thread overview] Message-ID: <bug-111820-4-0cf2iGjEcq@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-111820-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111820 --- Comment #8 from rguenther at suse dot de <rguenther at suse dot de> --- On Tue, 17 Oct 2023, crazylht at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111820 > > --- Comment #7 from Hongtao.liu <crazylht at gmail dot com> --- > (In reply to rguenther@suse.de from comment #6) > > On Mon, 16 Oct 2023, crazylht at gmail dot com wrote: > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111820 > > > > > > --- Comment #5 from Hongtao.liu <crazylht at gmail dot com> --- > > > (In reply to Richard Biener from comment #3) > > > > for (unsigned i = 0; i != skipn - 1; i++) > > > > begin = wi::mul (begin, wi::to_wide (step_expr)); > > > > > > > > (gdb) p skipn > > > > $5 = 4294967292 > > > > > > > > niters is 4294967292 in vect_update_ivs_after_vectorizer. Maybe the loop > > > > should terminate when begin is zero. But I wonder why we pass in 'niters' > > > Here, it want to calculate begin * pow (step_expr, skipn), yes we can just skip > > > the loop when begin is 0. > > > > I mean terminate it when the multiplication overflowed to zero. > for pow (3, skipn), it will never overflowed to zero. > To solve this problem once and for all, I'm leaning towards setting a threshold > in vect_can_peel_nonlinear_iv_p for vect_step_op_mul,if step_expr is not > exact_log2() and niter > TYPE_PRECISION (step_expr) we give up on doing > vectorization. Hm, yeah - that's probably best. > > > > As for the MASK_ thing the skip is to be interpreted negative (we > > should either not use a 'tree' here or make it have the correct type > > maybe). Can we even handle this here? It would need to be > > a division, no? > > > > So I think we need to disable non-linear IV or masked peeling for > > niter/aligment? But I wonder how we run into this with plain -O3. > I think we already disabled negative niters_skip in > vect_can_peel_nonlinear_iv_p. > > 416 /* Also doens't support peel for neg when niter is variable. > 1417 ??? generate something like niter_expr & 1 ? init_expr : -init_expr? > */ > 1418 niters_skip = LOOP_VINFO_MASK_SKIP_NITERS (loop_vinfo); > 1419 if ((niters_skip != NULL_TREE > 1420 && TREE_CODE (niters_skip) != INTEGER_CST) But we end up here with niters_skip being INTEGER_CST and .. > 1421 || (!vect_use_loop_mask_for_alignment_p (loop_vinfo) possibly vect_use_loop_mask_for_alignment_p. Note LOOP_VINFO_PEELING_FOR_ALIGNMENT < 0 simply means the amount of peeling is unknown. But I wonder how we run into this on x86 without enabling loop masking ... > 1422 && LOOP_VINFO_PEELING_FOR_ALIGNMENT (loop_vinfo) < 0)) > 1423 { > 1424 if (dump_enabled_p ()) > 1425 dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location, > 1426 "Peeling for alignement is not supported" > 1427 " for nonlinear induction when niters_skip" > 1428 " is not constant.\n"); > 1429 return false; > 1430 }
next prev parent reply other threads:[~2023-10-17 7:16 UTC|newest] Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-10-15 2:02 [Bug c/111820] New: GCC: 14: hangs with a simple while loop 141242068 at smail dot nju.edu.cn 2023-10-15 2:07 ` [Bug tree-optimization/111820] " pinskia at gcc dot gnu.org 2023-10-15 2:09 ` [Bug tree-optimization/111820] [13/14 Regression] Compiler time hog in the vectorizer with `-O3 -fno-tree-vrp` pinskia at gcc dot gnu.org 2023-10-16 7:14 ` rguenth at gcc dot gnu.org 2023-10-16 7:22 ` crazylht at gmail dot com 2023-10-16 7:43 ` crazylht at gmail dot com 2023-10-16 8:46 ` rguenther at suse dot de 2023-10-17 6:56 ` crazylht at gmail dot com 2023-10-17 7:16 ` rguenther at suse dot de [this message] 2023-10-17 9:13 ` crazylht at gmail dot com 2023-10-17 9:47 ` rguenth at gcc dot gnu.org 2023-10-23 1:16 ` cvs-commit at gcc dot gnu.org 2023-10-23 2:39 ` crazylht at gmail dot com 2023-10-23 9:42 ` [Bug tree-optimization/111820] [13 " rguenth at gcc dot gnu.org 2023-10-27 1:06 ` cvs-commit at gcc dot gnu.org 2023-10-27 1:18 ` crazylht at gmail dot com 2023-10-27 1:20 ` pinskia at gcc dot gnu.org 2023-10-27 3:29 ` pinskia 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-111820-4-0cf2iGjEcq@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).