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/99510] [11 Regression] Compile time hog in build_aligned_type since r11-7123-g63538886d1f7fc7c Date: Wed, 10 Mar 2021 10:53:11 +0000 [thread overview] Message-ID: <bug-99510-4-TrthhcKDa8@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-99510-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99510 --- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> --- Ah, OK. We're having a lot of vector CTORs we "vectorize" with load permutations like { 484 506 } and that runs into the pre-existing issue (there's a PR about this...) that we emit dead vector loads for all of the elements in the group, including gaps. Costing says they're even which possibly makes sense. We do a build_aligned_type for each emitted stmt and for some reason it's quite costly here (well, there's the awkward linear type variant list to walk ...). Caching should be possible but the load vectorization loop is already quite awkward. Meh. The rev. likely triggered this because we didn't cost the scalar root stmt before (the CTOR itself we replace). Doing that made the costing profitable. Having equal scalar and vector load cost makes fixing on the costing side difficult - the vector load should be an epsilon more expensive to avoid these issues. Note for some reason we have gazillion of type variants here. Huh. ~36070 variants per type. Ah. And _that's_ because build_aligned_type does for (t = TYPE_MAIN_VARIANT (type); t; t = TYPE_NEXT_VARIANT (t)) if (check_aligned_type (t, type, align)) return t; t = build_variant_type_copy (type); SET_TYPE_ALIGN (t, align); TYPE_USER_ALIGN (t) = 1; ^^^^ and check_aligned_type checks for an exact match TYPE_USER_ALIGN, but of course if 'type' wasn't aligned originally it won't find the created aligned type ... Fixing that fixes the compile-time issue.
next prev parent reply other threads:[~2021-03-10 10:53 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-10 9:09 [Bug tree-optimization/99510] New: " marxin at gcc dot gnu.org 2021-03-10 9:10 ` [Bug tree-optimization/99510] " marxin at gcc dot gnu.org 2021-03-10 10:13 ` rguenth at gcc dot gnu.org 2021-03-10 10:53 ` rguenth at gcc dot gnu.org [this message] 2021-03-10 12:14 ` cvs-commit at gcc dot gnu.org 2021-03-10 12: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-99510-4-TrthhcKDa8@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).