http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53623
Richard Guenther <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Depends on| |50176
Target Milestone|--- |4.7.2
--- Comment #4 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-06-11
09:47:15 UTC ---
Forwprop does
--- t.c.024t.ccp1 2012-06-11 11:32:13.791164397 +0200
+++ t.c.025t.forwprop1 2012-06-11 11:32:13.792164397 +0200
@@ -11,7 +11,7 @@
<bb 2>:
D.1751_2 = code[rdx_1(D)];
rdx_3 = (int64_t) D.1751_2;
- inst_4 = (uint8_t) rdx_3;
+ inst_4 = (uint8_t) D.1751_2;
rdx_5 = rdx_3 >> 8;
D.1752_6 = (int) inst_4;
D.1753_7 = dispatch[D.1752_6];
making D.1751_2 no longer single-use and thus no longer triggering combine.
Indeed looks related to 50176.
But while we certainly can teach forwprop to only consider single-use
chains (to never possibly cause this issue) it isn't a good solution.
In fact for properly optimizing this we need to know whether cheap
sub-reg like accesses are possible (combining (int) (uint8_t) (int64_t)
code[rdx_1] to simply extending the lower part of (int64_t) code[rdx_1]
without explicit truncation). This seems more fit for an RTL optimization
pass than for a tree pass if consider the forwprop "optimization" be done
in source like
#include <stdint.h>
typedef (*inst_t)(int64_t rdi, int64_t rsi, int64_t rdx);
int16_t code[256];
inst_t dispatch[256];
void an_inst(int64_t rdi, int64_t rsi, int64_t rdx) {
uint8_t inst;
inst = (uint8_t) code[rdx];
rdx = code[rdx];
rdx >>= 8;
dispatch[inst](rdi, rsi, rdx);
}
int main(void) {
return 0;
}
which you could easily get from some level of abstraction.
