public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/89059] Once we emit switchconf tables, we don't optimize them anymore Date: Sun, 29 Aug 2021 09:12:13 +0000 [thread overview] Message-ID: <bug-89059-4-J8TZftWAm8@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-89059-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89059 --- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> --- It is way too early, but on the other side the inlining decisions want to know if the switch is optimizable in certain way. So one possibility would be to lower as we currently do, but add optimizations to simplify and/or convert to some other form later after IPA. And another would be to just do the analysis phase of switches shortly before inlining and note (either in flags on GIMPLE_SWITCH or in an on-the-side data structure or whatever) what way we'd optimize the switch, take it into account during inlining cost computations and lower for real after IPA only. Though, e.g. if we decide to go with a value table for a switch in an inline function and if in all the inline copies we still decide to use the same value table, it would be nice to share the tables. But, if in each inlined copy VRP has different ranges and we can build different tables, we shouldn't share them... And there is another PR that we should use range info (ranger at this point) in the switch lowering decisions.
prev parent reply other threads:[~2021-08-29 9:12 UTC|newest] Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <bug-89059-4@http.gcc.gnu.org/bugzilla/> 2021-08-29 4:28 ` pinskia at gcc dot gnu.org 2021-08-29 9:12 ` jakub at gcc dot gnu.org [this message]
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-89059-4-J8TZftWAm8@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).