This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fix PR44281 (bad RA with global regs)


On 02/19/2016 03:03 PM, Bernd Schmidt wrote:
In this PR, we generate unnecessarily bad code for code that declares a
global register var. Since global regs get added to fixed_regs, IRA
never considers them as candidates. However, we do seem to have proper
data flow information for them. In the testcase, the global reg dies,
some operations are done on temporary results, and the final result
stored back in the global reg. We can achieve the desired code
generation by reusing the global reg for those temporaries.

Bootstrapped and tested on x86_64-linux. Ok? An argument could be made
not to use this for gcc-6 since global register vars are both not very
important and not very well represented in the testsuite.


Bernd

global-regalloc.diff


	PR rtl-optimization/44281
	* hard-reg-set.h (struct target_hard_regs): New field
	x_fixed_nonglobal_reg_set.
	(fixed_nonglobal_reg_set): New macro.
	* reginfo.c (init_reg_sets_1): Initialize it.
	* ira.c (setup_alloc_regs): Use fixed_nonglobal_reg_set instead
	of fixed_reg_set.

	PR rtl-optimization/44281
	* gcc.target/i386/pr44281.c: New test.
It sounds like Richi wants to table this to gcc-7, which I can understand. So I'm not going to dig into the patch itself, just touch on the high level stuff.

Global register variables are currently documented as "The register is reserved entirely for this use, and will not be allocated for any other purpose". That would need to be fixed.

When David W. and I were working through the docs on this stuff in 2015, I don't think that either of us considered the possibility that the register could be used for temporaries between a use of the global register var (where it dies) and an assignment to the global register var (rebirth).

As long as our dataflow is good, using the global register var for a temporary in that window seems like a useful thing to do. So I think the biggest concern would be any kind of implicit use. I'm thinking of function calls where the callee expects the global register var to have the right value, perhaps asms as well (someone might reference the global var in the asm, but not list it in the sets/uses/clobbers because it wasn't really necessary in the past).

Thoughts?

jeff



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]