This is the mail archive of the
mailing list for the GCC project.
Re: Emit more REG_EQUIV notes for function args (PR42235)
- From: Jeff Law <law at redhat dot com>
- To: Bernd Schmidt <bernds at codesourcery dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 14 Jul 2010 12:54:39 -0600
- Subject: Re: Emit more REG_EQUIV notes for function args (PR42235)
- References: <4C3D9C06.firstname.lastname@example.org>
On 07/14/10 05:14, Bernd Schmidt wrote:
Right, but what guarantee do we have that the conversion insn doesn't
clobber a function argument register? ISTM that to be safe you
actually have to scan the insns created by gen_extend_insn to ensure
they don't clobber something important.
When moving arguments into pseudos, we are being very careful not to
emit any instructions that could possibly clobber other argument
registers. Currently, we generate unnecessarily complicated sequences
of code for simple zero or sign extensions.
With this patch, we check can_extend_p and the necessary predicates to
see if an extend insn is available for the conversion we have to do.
I'm not an expert on what ports do these days, but I did work on a port
(mn10200) where conversion "insns" where implemented as special function
calls under the hood. I don't recall if we allowed those special
function calls to have visible side effects, but if they did, they'd
show up as clobbers/uses attached to the normal conversion insn. Of
course the mn102 is dead, but I think it's method for implementing
conversions was valid and if another port were to do something similar
it would likely not interact well with your change.
Creating more REG_EQUIVs seems like a good idea to me.
so, we emit the insn directly, and create a REG_EQUIV note of the form
Reload can't really do anything with these yet,In theory, given the REG_EQUIV note we ought to get an entry in
reg_equiv_mem, which the code I'm working on knows it can use instead of
shoving the pseudo into a stack slot. Effectively, my code will
rematerialize the argument from the equivalent memory location
regardless of the number of uses.
but there's an optimization in the register allocator to move argument
loads directly before their use if there's only one use. On Thumb-2
this happens already, we seem to generate better code than before.
Unfortunately Thumb-1, which the PR is about, has some other problems
which I'll try to fix later.