On Mon, Jan 16, 2017 at 08:23:32AM +0100, Richard Biener wrote:
> > I think it is not as bad. I think the problem is only when you
> > force_operand 1) after expansion 2) with complicated expression.
> > I think if you force_operand just with something that appears in some insn,
> > it is very unl
On Sun, 15 Jan 2017, Jakub Jelinek wrote:
> On Sat, Jan 14, 2017 at 09:16:11PM -0700, Jeff Law wrote:
> > > 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 exp
On Sat, Jan 14, 2017 at 09:16:11PM -0700, Jeff Law wrote:
> > 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 e
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_m
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_
