On Wed, Dec 12, 2012 at 12:47 PM, Yuri Rumyantsev <ysrum...@gmail.com> wrote: > Hi Uros, > > This fix is for all x86 platforms, we tested it on core2/corei7, > atom/atom2 and AMD and got performance improvement +6% -- +11%. So I > don' think we need to introduce additioanl tune feature. > > Sorry for my typo with gcc version - I ment mainline only since 4.7 > does not use LRA.
Btw, if it's a performance improvement all over the board why not adjust the patterns itself to not allow memory operands? Thus, why restrict it to combine not creating this instruction? (My -Os comment still stands) Richard. > Thanks. > Yuri. > > > > 2012/12/12 Uros Bizjak <ubiz...@gmail.com>: >> On Wed, Dec 12, 2012 at 12:27 PM, Yuri Rumyantsev <ysrum...@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. >> >> Is this true for all x86 targets? I have no objections to the >> implementation, but these fine-tunings should be declared in >> ix86_tune_features[] array, and used as conditions involving >> TARGET_xxx in the code. Please see many examples in the i386 source >> dir. >> >>> Is it OK for 4.8 and mainline? >> >> Hm, currently 4.8 _is_ mainline. Did you mean 4.7? >> >> Thanks, >> Uros.
