On Wed, Dec 14, 2016 at 04:31:19PM +0100, Jakub Jelinek wrote:
> > Could you do a gcc_checking_assert (INSN_UID (INSN) <= max_uid_known)
> > in the LOG_LINKS and INSN_COST defines? It is hard to check if you
> > caught every use.
>
> Like this? Bootstrapped/regtested again on x86_64-linux and i
On Wed, Dec 14, 2016 at 03:36:23AM -0600, Segher Boessenkool wrote:
> On Wed, Dec 14, 2016 at 09:34:44AM +0100, Jakub Jelinek wrote:
> > Here is updated patch that does that. I had to change the combiner
> > in a couple of places, because combiner is very unhappy if new instructions
> > (with uids
On Wed, Dec 14, 2016 at 09:34:44AM +0100, Jakub Jelinek wrote:
> Here is updated patch that does that. I had to change the combiner
> in a couple of places, because combiner is very unhappy if new instructions
> (with uids above the highest) are inserted into the insn stream,
> e.g. FOR_EACH_LOG_L
On Wed, 14 Dec 2016, Jakub Jelinek wrote:
> On Tue, Dec 13, 2016 at 10:05:58AM +0100, Richard Biener wrote:
> > Hmm, so the "easier" fix would be to always create a debug insn
> > right after INSN setting a new debug reg to SRC and then doing the
> > replacement with the new debug reg? With the "
On Tue, Dec 13, 2016 at 10:05:58AM +0100, Richard Biener wrote:
> Hmm, so the "easier" fix would be to always create a debug insn
> right after INSN setting a new debug reg to SRC and then doing the
> replacement with the new debug reg? With the "optimization"
> to not do that for some single use
On Tue, Dec 13, 2016 at 10:05:58AM +0100, Richard Biener wrote:
> > The following patch just throws away expressions that have 32 register
> > references in there, I think that is so huge that it will be really very
> > unlikely to be beneficial in the debug info and var-tracking would likely
> > t
On Mon, 12 Dec 2016, Jakub Jelinek wrote:
> Hi!
>
> On the following testcase (where I've failed to reduce it without the
> header, got to over 70KB with both delta and creduce) we end up with huge
> RTL expressions in debug insns that just slow down combiner as well as
> var-tracking etc. too mu
Hi!
On the following testcase (where I've failed to reduce it without the
header, got to over 70KB with both delta and creduce) we end up with huge
RTL expressions in debug insns that just slow down combiner as well as
var-tracking etc. too much.
Generally, at GIMPLE level we try to keep the debug
