On 06/12/14 10:21, Kai Tietz wrote:
Hello,
I updated i386.md part of the patch. Initial patch included handling
of blockage, which is obviously superflous. Additionally I merged
32-bit and 64-bit peephole2 versions by using mode-specifier W.
ChangeLog
2014-06-12 Kai Tietz <kti...@redhat.com>
* config/i386/i386.md (peehole2): To combine
indirect jump with memory.
2014-06-12 Kai Tietz <kti...@redhat.com>
* gcc.target/i386/indjmp-1.c: New test.
Tested for i686-pc-cygwin, and x86_64-unknown-linux-gnu. Ok for apply?
So you may have answered this already, but why can't this be a combiner
pattern? We have the first insn which sets a reg which is used and
dies in the subsequent insn. There's a data dependency so the combiner
ought to be trying to smash these two insns together.
Or is it the case that combine does smash them together, but we get a
bad register allocation and generate spills?
with addition of adding a second peephole2 pass after sched2 pass, I
was able to get some improvement for PR target/39284. I think by this
addition we can close bug as fixed.
Additionally additional peephole2 pass shows better results for PR
target/51840 testcase with disabled ASM_GOTO, too.
2014-06-12 Kai Tietz <kti...@redhat.com>
PR target/39284
* passes.def (pass_peephole2): Add second peephole2
run after sched2 pass.
Need to resolve the prior question before digging into this. Obviously
if combine is a better place to handle this optimization, then this
patch may not be needed.
Jeff
