On Wed, Dec 12, 2012 at 1:55 PM, Uros Bizjak <ubiz...@gmail.com> wrote: > On Wed, Dec 12, 2012 at 12:44 PM, Richard Biener > <richard.guent...@gmail.com> wrote: > >>> This fix is aimed to remove performance degradation introduced by new >>> LRA phase that in fact is combining problem. Gcc combiner does >>> propagation of memory load to if-then-else gimple that was splitted >>> back by old reload phase. LRA does not perform such splitting. To >>> avoid performance slowdown on important benchmark (this is true for >>> all x86 targets) we decided to enhance 'ix86_legitimate_combined_insn' >>> with a check on such propagation and consider such conditional >>> instruction with memory operand as illegal one from performance point >>> of view. >>> >>> The fix was bootstrapped and regtested for x86-64. >>> Is it OK for 4.8 and mainline? >> >> Isn't it a win for -Os though? Thus, optimize_insn_for_size ()? It can >> also increase register pressure, no? So eventually this splitting should >> be done post-reload only. Not sure what appropriate machinery there is, >> besides from mdreorg (or split itself). > > So, you are proposing to use peephole2 with (match_scratch) > conditional temporary?
Yes, if that works. (sounds backward to me having a peephole split one insn into two ... ;)) Richard. > Uros.
