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: [PATCH, PR61446] Fix mode for register copy in REE pass


On 06/10/14 01:42, Ilya Enkovich wrote:
Hi,

This patch fixes PR61446.  The problem appears when we insert value copies after transformations. We use the widest extension mode met in a chain, but it may be wider than original destination register size.  This patch checks it and use smaller mode if required.

Bootstrapped and tested on linux-x86_64.

Does it look OK?

Thanks,
Ilya
--
2014-06-09  Ilya Enkovich  <ilya.enkovich@intel.com>

	PR 61446
	* ree.c (find_and_remove_re): Narrow mode for register copy
	if required.
The whole point behind the 61094 change was to avoid this kind of issue. ie, before eliminating an extension which requires a copy, make sure the copy is going to be valid (single insn that is recognizable and satisfies its constraints). If the copy is not going to be valid, then suppress the extension elimination.

It's not working as desired because of a relatively simple goof.

When I wrote the changes for 61094, I copied the code which created the new insns from find_and_remove_re into combine_reaching_defs -- the idea being we want to generate the same insn in combine_reaching_defs that will be generated in find_and_remove_re. In combine_reaching_defs we generate, validate & throw it away. In find_and_remove_re we generate and insert it into the insn stream.

The subtle issue missed as that in find_and_remove_re, we have already transformed the defining insn. ie, the destination of the defining insn is in the widened mode. That is _not_ the case in combine_reaching_defs.

So combine_reaching_defs is not testing the same insn that will be created by find_and_remove_re. The insns have the same structure, but the modes of the operands are different.

For 61094, that little difference was not important. It *is* important for 61446. Thankfully the fix is trivial and I've confirmed that 61094 stays fixed and that it fixes 61446. Going through the bootstrap & regression process now.

Jeff


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