int f(int i, int b, int *c) { int ii; if (b) ii = i +1; else { *c = ii = i+1; } return ii; } Note I added compile time hog and memory hog as this causes too many bb to be there and more RTL than needed.
Confirmed, but I don't see it happening at the RTL level either in 3.5.0, so I'll remove the TREE keyword. The optimization did happen with 2.95.3 though. I'll mark it as a regression, even if I expect only a tree-level solution to happen (maybe already with GCSE), so it won't probably be fixed for the 3.3 branch or 3.4 branch.
(In reply to comment #1) > (maybe already with GCSE) ^^^^ I meant GVN-PRE
I had forgot to say it works on powerpc-apple-darwin with all compilers so that is why I had TREE there.
I should note that it does happen at -Os on x86-pc-linux-gnu.
Subject: Re: [3.3/3.4/3.5 Regression] SSAPRE misses obivous redudent expression "giovannibajo at libero dot it" <gcc-bugzilla@gcc.gnu.org> writes: | even if I expect only a tree-level solution to happen (maybe already with | GCSE), so it won't probably be fixed for the 3.3 branch or 3.4 branch. yes, you're right about 3.3.x. -- Gaby
This should be fixed in GVNPRE.
Actually, i'm not sure what you expect to happen here. We won't hoist this because there is no point in hoisting this, it doesn't reduce the total number of computations along any path, but does increase the lifetime. There is nothing redundant along any single path in the program.
yes, but if GVNPRE hoists the operation, we end up with: int f(int i, int b, int *c) { int ii; ii = i+1; if (b) ; else *c = ii; return ii; } that can be later simplified to: int f(int i, int b, int *c) { int ii; ii = i+1; if (!b) *c = ii; return ii; }
Theoretically yes, but no PRE algorithm will do what you suggest, you need a generic code hoisting algorithm. The transformation you suggest violates the optimality conditions of PRE, even if it can later make better code, so it wouldn't be performed. In short, PRE is for partial redundancies, not a cost based generic code hoister, so this is not a case of PRE missing obvious redundant expressions. There is no redundant expression (it occurs once along each path) here that it could eliminate, there is simply an expression that could be hoisted one block up.
An example of where not doing hurts: int ii; int f(int i, int b, int *c) { if (b) ii = i +1; else { *c = ii = i+1; } return ii; } As there is a store to ii and then a load from it.
Not a hog, just a missed optimization. Let's reserve the *hog keywords for *real* hogs...
(In reply to comment #10) > An example of where not doing hurts: > int ii; > int f(int i, int b, int *c) > { > if (b) > ii = i +1; > else > { > *c = ii = i+1; > } > return ii; > } > > As there is a store to ii and then a load from it. I'm not sure what you are talking about. At the tree level, there is only a store.
(In reply to comment #8) > yes, but if GVNPRE hoists the operation, we end up with: > > int f(int i, int b, int *c) > { > int ii; > ii = i+1; > if (b) > ; > else > *c = ii; > return ii; > } > > that can be later simplified to: > > int f(int i, int b, int *c) > { > int ii; > ii = i+1; > if (!b) > *c = ii; > return ii; > } > This is still not faster code, only smaller code. And you'll note that with -Os, this is what we do. In any case, i have no plan sto make GVN-PRE do this type of hoisting, as i'm not so interested in code size.
Gosh, I don't even see how this is a regression. Geez. Come on guys.
Mark, can we move the milestone on this one please? There is no way this will be fixed for GCC 4.0.
I'm going to go a step further and mark this INVALID. Since we already do the right thing at -Os, and there's no evidence that we're actually generating slower code at -O2, I'm not worried about this issue. If there's evidence that the code we're generating is slower than with a previous compiler, post assembly code and timing information that shows that.