Collecting pending patches for GCC 4.6 that can be applied after GCC 4.5 branches
Created attachment 19002 [details]
Patch for better reassignment of pseudos during/after reloading
Discussion here: http://gcc.gnu.org/ml/gcc-patches/2009-11/msg00502.html
Created attachment 19003 [details]
Avoid incorrect accumulation of registers in ALLOCNO_TOTAL_CONFLICT_HARD_REGS
A minor code generation improvement by avoiding incorrect accumulation of registers in ALLOCNO_TOTAL_CONFLICT_HARD_REGS.
Created attachment 19038 [details]
patch to improve register allocation
Created attachment 19212 [details]
patch for frame-pointerless mcount
Patch to turn TARGET_FUNCTION_VALUE_REGNO_P macro into a hook.
Handle ADDR_EXPR in SCEV
Created attachment 19969 [details]
Patch to generate bit instructions for H8 target and other minor enhancements
Patch to generate bit instructions for H8 target and other minor enhancements.
This patch addresses the discussion on the gcc-patches mailing list,
Other PRs block this one, not the other way around.
Created attachment 20009 [details]
Patch for SH to prevent the generation of the pop instruction in the delay slot after 'rte'
Patch for SH to prevent the generation of the pop instruction in the
delay slot after 'rte' for sh and sh2 targets.
(In reply to comment #10)
> Patch for SH to prevent the generation of the pop instruction in the
> delay slot after 'rte' for sh and sh2 targets.
Rather than attach patches here, it would be better to link to the mailing message where the patch was approved. Otherwise, it is not clear whether these are tentative patches or approved patches.
> Rather than attach patches here, it would be better to link to the mailing
> message where the patch was approved.
Understood. This patch has been approved,
And if the patch fixes a PR, it is better to link to the patch from the original PR and add the PR to the list of bugs that this PR depend on (you can use the alias "4.6" in the field "Bug X blocks" of your PR).
Most of the h8_enhancement patch has been applied. Unfortunately, one aspect of that change (reordering alternatives in the logical and, ior, xor patterns) causes codesize & performance regressions and has not been installed. The fundamental problem is the bit insns do not set cc0 and as a result we often miss opportunities to remove tst insns.
I'm withdrawing the color.patch2. While the patch makes sense in theory and seems to help x86, it's causing clear regressions on other targets such as the mn103. I've been unable to resolve the regressions without making the patch basically worthless on x86. At this point I just don't see that it's worth the effort.
Closing. Appropriate patches & dependencies moved to the 4.7 pending patches meta-bug.