This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] combine: If a parallel I2 was split, do not allow a new I2 (PR64268)
- From: Segher Boessenkool <segher at kernel dot crashing dot org>
- To: Paolo Bonzini <bonzini at gnu dot org>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Tue, 16 Dec 2014 13:03:24 -0600
- Subject: Re: [PATCH] combine: If a parallel I2 was split, do not allow a new I2 (PR64268)
- Authentication-results: sourceware.org; auth=none
- References: <35b5f631a14f76c9305c7bfc8e8bf5fd764ec845 dot 1418640924 dot git dot segher at kernel dot crashing dot org> <548F0372 dot 4030101 at gnu dot org> <20141215162447 dot GA26283 at gate dot crashing dot org> <20141216132822 dot GA15706 at gate dot crashing dot org>
On Tue, Dec 16, 2014 at 07:28:22AM -0600, Segher Boessenkool wrote:
> and "type0" is when it didn't
> do either but still ended up with I1 and I2 the same UID (I think it
> might be called with the same insn twice; not a good thing, it does
> not know how to handle this; and it is really worrisome that it then
> sometimes succeeds in combining it).
... and when I make try_combine immediately refuse duplicates in I0,I1,I2
everything works again.
When INSN_UID (i1) == INSN_UID (i2), calling df_insn_delete (i1) does
set the "should be deleted" flag on i2 instead, but try_combine later
calls df_insn_rescan (i2) which resets it again. This is icky and
looks very wrong in the debug dump, but it does work fine.
Doing an (effictively) 2->2 combine like this still feels quite unsafe
wrt combine possibly looping, but it has worked for over twenty years.
Bootstrapping, making new test results, will send a new patch later
today.
Thanks for pushing me to look much closer,
Segher