On 11/19/19 10:12 AM, Jakub Jelinek wrote:
On Mon, Nov 18, 2019 at 03:34:35PM +0100, Martin Liška wrote:
Now, I believe with the if to gswitch optimization these will only rarely
kick in, because the IL will have switches that reassoc doesn't handle,
instead of series of ifs.
Yes, so my question is whether reassoc can handle gswitch statements similar
to series of if statements? Note that use can write explicitly something like:
I don't see how. Either the cswitch pass runs early, and then you need to
take it into account when deciding whether to expand it as series of ifs or
table lookup or bittest (say, realize you'd need just a single condition to
cover everything and go with if series), or it runs late and then on the
other side if reassoc turned gswitch into if series without taking into
account other possibilities like table lookup, it could pessimize stuff.
So, IMHO cswitch should he able to do this too.
I agree with you that we should teach switch lowering to also consider the
transformation that reassoc does. I understand it as a generalized bit test,
and I would be happy to implement that on gswitch level. Which leads us
back to need for if-to-switch conversion pass that will enable such
optimization.
My counter-example is following:
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/reassoc-32.c
b/gcc/testsuite/gcc.dg/tree-ssa/reassoc-32.c
index 944362ad076..58f9737b918 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/reassoc-32.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/reassoc-32.c
@@ -6,10 +6,15 @@
int test (int a, int b, int c)
{
- if ( a == 10 || a == 12 || a == 26)
- return b;
- else
- return c;
+ switch (a)
+ {
+ case 10:
+ case 12:
+ case 26:
+ return b;
+ default:
+ return c;
+ }
}
int main ()
Note that I see both representation in the source code equivalent.
It's probably just a matter of taste ;)
Martin
switch (a)
case 0...30:
return 1;
case 32:
return 1;
case 34:
return 1;
which won't be optimized by reassoc. While it can handle something
0<=A<=30|A==32|A==34.
Jakub
