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] Fix RTL sharing bug in loop-doloop.c (PR target/79080)


On 01/14/2017 06:36 AM, Jakub Jelinek wrote:
Hi!

The force_operand on complex count expression in doloop_modify can invoke
various expander routines that are assuming there is rtl unsharing after
them (which is the case for expansion).  When later optimizations invoke
the expander (e.g. expand_mult in this case), they use
unshare_all_rtl_in_chain on the sequence.  The following patch does that for
doloop.  The count expression is already known not to be shared with
anything else (we do copy_rtx on it first and then create new rtls around it
if needed), so for that if it occurs just once in the sequence, we don't
need to unshare it.  For subexpression of condition I'm not sure, which is
why I've forced unsharing even if it occurs just once and is not shareable
part of the condition like REG.

Bootstrapped/regtested on powerpc64-linux, ok for trunk?

2017-01-14  Jakub Jelinek  <jakub@redhat.com>

	PR target/79080
	* loop-doloop.c (doloop_modify): Call unshare_all_rtl_in_chain on
	sequence.  Formatting fixes.
	(doloop_optimize): Formatting fixes.

	* gcc.dg/pr79080.c: New test.
So do we have a more general problem here -- we use force_operand in all kinds of contexts, particularly in the RTL loop optimizers. If force_operand can introduce undesirable sharing, then isn't more code prone to this problem?

So just to be clear, I'm OK with this change as-is, I just worry we have other places that are structure sharing assumption problems waiting to happen.

jeff


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