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.

      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: link
Be 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).