On Fri, Feb 14, 2014 at 3:50 PM, Kai Tietz <ktiet...@googlemail.com> wrote: > 2014-02-14 15:40 GMT+01:00 Uros Bizjak <ubiz...@gmail.com>: >> On Fri, Feb 14, 2014 at 2:48 PM, Kai Tietz <ktiet...@googlemail.com> wrote: >>> 2014-02-14 13:55 GMT+01:00 Uros Bizjak <ubiz...@gmail.com>: >>>> Hello! >>>> >>>>> 2014-02-14 Kai Tietz <kti...@redhat.com> >>>>> >>>>> PR target/60193 >>>>> * config/i386/i386.c (ix86_expand_prologue): Use >>>>> rax register as displacement for restoring %r10, %eax. >>>>> >>>>> Regression-tested for x86_64-unknown-linux-gnu, and >>>>> x86_64-w64-mingw32, and i686-w64-mingw32. Ok for apply? >>>> >>>> No, you should check allocate to satisfy x86_64_immediate_operand and >>>> put it into a temporary register if not. There is no need to always >>>> force constant into a temporary. >>> >>> Well, in general I would agree to your statement. But in this case we >>> have already the required value in rax-register loaded. So I don't >>> see the advantage of using in case of <2^32 constant for those >>> restore-operation. At least for code-size optimization it looks to me >>> better and I am not aware that usage of register is here more >>> expensive. I might be wrong about later. >> >> Ah, I was not aware of the fact that eax already holds the value. >> However, there were some problems with the patch: eax RTX is >> unnecessarily regenerated in the wrong mode, UNITS_PER_WORD should be >> subtracted instead of added - you can use displacement+offset >> addressing instead. >> >> Something like (untested) attached patch. >> >> Uros. > > No, the patch I attached works fine. To substract here UNITS_PER_WORD > is in fact a bug. As description see how we modify allocate on > pushing.
This fact was not mentioned in the ChangeLog. So, simply change + t = plus_constant (Pmode, t, -UNITS_PER_WORD); to t = plus_constant (Pmode, t, UNITS_PER_WORD); in my patch, and it should generate correct offset+displacement address. Please also add the testcase from the PR. Uros.
