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: Emit more REG_EQUIV notes for function args (PR42235)


On 07/14/10 05:14, Bernd Schmidt wrote:
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.
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.

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.


  If
so, we emit the insn directly, and create a REG_EQUIV note of the form
(sign_extend (mem)).
Creating more REG_EQUIVs seems like a good idea to me.



Reload can't really do anything with these yet,
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.
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.


Jeff



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