------- Comment #56 from steven at gcc dot gnu dot org 2008-12-10 21:44 ------- Re. comment #52:
I've pasted the test case in the audit trail here as plain text -- it's pretty small and it shows the problem nicely. The issue is that with -Os, on all targets, the line, propsRes->lc = prop0; is replaced with: propsRes->lc = (int) (int) (prop0.24 % 45); // with prop0.24 = propsData[0]; so there is no div/mod instruction in the original code, but one appears as a result of the final value replacement optimization. With -O2 there is also a div instruction, but I am not sure where it comes from (I suspect loop header copying, but it's inconsequential for this issue anyway). The problem is not that we don't give CSE enough information. The problem is reported for a GCC 4.3 based compiler, which still has libcall notes. So at least in theory, CSE in GCC 4.3 should have all the information available to optimize away the mod instruction. Apparently the result is just not available. The bottom line, then, is still that the final value replacement has introduced an operation at the tree level that doesn't have a matching RTL instruction. In this case a mod insn that makes gcc produce a libcall to umodsi. I think Zdenek is right in comment #54: We should reincarnate expression_expensive_p in some form such that it takes into account (or makes a reasonable guess about) which instructions are particularly expensive. Apparently, the old cost check was too conservative (it tested the expression cost against spill cost, ignoring further optimization opportunities). So we need to test for something else than before. Maybe we should not replace if the final value is not a constant? Or if it is an expression involving div/mod? Can we test somehow how many insns the final value replacement computation would take (maybe re-use the inliner heuristics)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
