[Bug tree-optimization/87925] [missed-optimization] Distinct-value if-then-else chains treated differently than switch statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87925 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #7 from Andrew Pinski --- Dup of a much older bug (PR 14799) ... *** This bug has been marked as a duplicate of bug 14799 ***
[Bug tree-optimization/87925] [missed-optimization] Distinct-value if-then-else chains treated differently than switch statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87925 --- Comment #6 from Martin Liška --- (In reply to Eyal Rozenberg from comment #5) > (In reply to Martin Liška from comment #3) > > Currently we only do switch -> balanced decision tree (read series of > > if-then-else statements). Well definitely a potentially enhancement, > > question is whether it worth doing that.. > > That is a question for another bug. I'm just saying that these two cases (or > some expansion thereof, e.g. with some fallthrough on the case side, or with > several distinct values in each if statement) should be treated the same. > i.e. whatever optimizations are considered for one of them should be > considered for the other. Sure, agree with that. > > (In reply to Martin Liška from comment #4) > > This is not problem because it's a const expression that is evaluate in C++ > > front-end. Thus you don't get any penalty. > > The specific use example at the link is a static_assert, but the in() > function there works with runtime values as well. So - not just compile-time > computation. Another example - un-type-erasure dispatches, which may go into > tight loops: https://stackoverflow.com/a/38924396/1593077 Indeed.
[Bug tree-optimization/87925] Missed optimization: Distinct-value if-then-else chains treated differently than switch statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87925 --- Comment #5 from Eyal Rozenberg --- (In reply to Martin Liška from comment #3) > Currently we only do switch -> balanced decision tree (read series of > if-then-else statements). Well definitely a potentially enhancement, > question is whether it worth doing that.. That is a question for another bug. I'm just saying that these two cases (or some expansion thereof, e.g. with some fallthrough on the case side, or with several distinct values in each if statement) should be treated the same. i.e. whatever optimizations are considered for one of them should be considered for the other. (In reply to Martin Liška from comment #4) > This is not problem because it's a const expression that is evaluate in C++ > front-end. Thus you don't get any penalty. The specific use example at the link is a static_assert, but the in() function there works with runtime values as well. So - not just compile-time computation. Another example - un-type-erasure dispatches, which may go into tight loops: https://stackoverflow.com/a/38924396/1593077
[Bug tree-optimization/87925] Missed optimization: Distinct-value if-then-else chains treated differently than switch statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87925
--- Comment #4 from Martin Liška ---
(In reply to Eyal Rozenberg from comment #0)
> Have a look at this GodBolt example: https://gcc.godbolt.org/z/zR03rA
>
> On one hand, we have:
>
> void foo(int i) {
> switch (i) {
> case 1: boo<1>(); break;
> case 2: boo<2>(); break;
> case 3: boo<3>(); break;
> case 4: boo<4>(); break;
> // etc. etc.
> }
> }
>
> on the other hand we have the same, but using an if-then-else chain:
>
> void bar(int i) {
> if (i == 1) boo<1>();
> else if (i == 2) boo<2>();
> else if (i == 3) boo<3>();
> else if (i == 4) boo<4>();
> // etc. etc.
> }
>
> The switch statement gets a jump table; the if-then-else chain - does not.
> At the link, there are 20 cases; g++ starts using a jump table with 4 switch
> values.
Agree with that, but I would say that when having a lot of cases, switch is
more
natural constructor. The code looks nicer ;)
>
> This is not just a matter of programmers needing to remember to prefer
> switch statements (which it's better not to require of them), but rather
> that if-then-else chains are sometimes generated by expansion of templated
> code, e.g. this example for checking for membership in a set of values (=
> all values of an enum):
>
> https://stackoverflow.com/a/53191264/1593077
This is not problem because it's a const expression that is evaluate in C++
front-end.
Thus you don't get any penalty.
[Bug tree-optimization/87925] Missed optimization: Distinct-value if-then-else chains treated differently than switch statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87925 Martin Liška changed: What|Removed |Added Severity|normal |enhancement --- Comment #3 from Martin Liška --- (In reply to Richard Biener from comment #2) > IIRC there was some work turning if-then-else chains into switches (and > possibly back to a tree) Currently we only do switch -> balanced decision tree (read series of if-then-else statements). Well definitely a potentially enhancement, question is whether it worth doing that..
[Bug tree-optimization/87925] Missed optimization: Distinct-value if-then-else chains treated differently than switch statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87925 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2018-11-08 CC||marxin at gcc dot gnu.org Component|rtl-optimization|tree-optimization Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- IIRC there was some work turning if-then-else chains into switches (and possibly back to a tree)
