| Message ID | 1430757479-14241-7-git-send-email-amonakov@ispras.ru |
|---|---|
| State | New |
| Headers | show |
On 05/04/2015 10:37 AM, Alexander Monakov wrote: > With this patch at hand, I'd like to discuss a code generation problem, which > my patch solves only partially. FWIW, it passes bootstrap/regtest on x86-64. > > With other patches in series applied, GCC with -fno-plt can generate tail > calls in PIC mode more frequently, but sometimes poorer code is generated. > I've tried to look for possible causes, and found one issue so far. > > Consider the following testcase: > > void foo1(int a, int b, int c, int d, int e, int f, int g, int h); > int bar(int x); > void foo2(int a, int b, int c, int d, int e, int f, int g, int h) > { > bar(a); > foo1(a, b, c, d, e, f, g, h); > } > > Comparing x86 code generation with -O2 -m32 and with/without -fPIC, you can > see that -fPIC happens to produce smaller code. Without -fPIC, GCC > saves/restores all arguments before/after call to 'bar'. > > The reason for that is without -fPIC, GCC performs tail call optimization on > 'foo1', and that causes it to drop REG_EQUIV notes for incoming arguments in > fixup_tail_calls. After that, code generation diverges at IRA stage, where > lack of equivalences prevents loads of pseudos to be moved to the point of > first use. > > The patch tries to repair the problem by allowing REG_EQUIV notes to be > resynthesized at ira init for loads that happen via `argp' rtx. It helps for > the simple testcase above, but not for problematic Clang/LLVM functions where > I noticed the issue. > > I hope there's a way around the 'big hammer' approach of fixup_tail_calls. > Might it be possible instead of dropping REG_EQUIV notes, to copy incoming > arguments into other pseudos just prior to stack pointer adjustment in > preparation for tailcall? Isn't the whole point of dropping the notes to indicate that those argument slots are not longer guaranteed to hold the value at all points throughout the function? That can certainly be relaxed, but you'll have to have some kind of code to analyze the data in the argument slots to ensure they haven't changed. You can't just blindly put the notes back if I remember this stuff correctly. Jeff
diff --git a/gcc/ira.c b/gcc/ira.c index ea2b69f..e6b82e2 100644 --- a/gcc/ira.c +++ b/gcc/ira.c @@ -3001,13 +3001,16 @@ validate_equiv_mem (rtx_insn *start, rtx reg, rtx memref) /* This used to ignore readonly memory and const/pure calls. The problem is the equivalent form may reference a pseudo which gets assigned a call clobbered hard reg. When we later replace REG with its equivalent form, the value in the call-clobbered reg has been changed and all hell breaks loose. */ - if (CALL_P (insn)) + rtx addr = XEXP (memref, 0); + if (GET_CODE (addr) == PLUS && GET_CODE (XEXP (addr, 1)) == CONST_INT) + addr = XEXP (addr, 0); + if (CALL_P (insn) && addr != arg_pointer_rtx) return 0; note_stores (PATTERN (insn), validate_equiv_mem_from_store, NULL); /* If a register mentioned in MEMREF is modified via an auto-increment, we lose the equivalence. Do the same if one
With this patch at hand, I'd like to discuss a code generation problem, which my patch solves only partially. FWIW, it passes bootstrap/regtest on x86-64. With other patches in series applied, GCC with -fno-plt can generate tail calls in PIC mode more frequently, but sometimes poorer code is generated. I've tried to look for possible causes, and found one issue so far. Consider the following testcase: void foo1(int a, int b, int c, int d, int e, int f, int g, int h); int bar(int x); void foo2(int a, int b, int c, int d, int e, int f, int g, int h) { bar(a); foo1(a, b, c, d, e, f, g, h); } Comparing x86 code generation with -O2 -m32 and with/without -fPIC, you can see that -fPIC happens to produce smaller code. Without -fPIC, GCC saves/restores all arguments before/after call to 'bar'. The reason for that is without -fPIC, GCC performs tail call optimization on 'foo1', and that causes it to drop REG_EQUIV notes for incoming arguments in fixup_tail_calls. After that, code generation diverges at IRA stage, where lack of equivalences prevents loads of pseudos to be moved to the point of first use. The patch tries to repair the problem by allowing REG_EQUIV notes to be resynthesized at ira init for loads that happen via `argp' rtx. It helps for the simple testcase above, but not for problematic Clang/LLVM functions where I noticed the issue. I hope there's a way around the 'big hammer' approach of fixup_tail_calls. Might it be possible instead of dropping REG_EQUIV notes, to copy incoming arguments into other pseudos just prior to stack pointer adjustment in preparation for tailcall?