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]

Re: Old patch: combine.c/i386.md tweaks to improve strcmp() builtin


On Sat, Nov 25, 2000 at 12:26:24PM +0000, Bernd Schmidt wrote:
> On Sat, 30 Sep 2000, Zack Weinberg wrote:
> 
> > 	* combine.c (try_combine): Remove redundant test.
> 
> This one is obviously OK.

I can't bootstrap at the moment because my system headers are hosed
(ill-considered upgrade side effects) but as soon as I get that
straightened out, I'll split this out and apply it.

> > 	(use_crosses_set_p): If the last set has been deleted, it
> > 	doesn't count.
> 
> I don't think this is correct.  Consider a case where you have two
> sets with cuids > from_cuid; only the second one is in reg_last_set,
> and if it's deleted, you'll end up erroneously returning 0.
> Why is there an insn with INSN_DELETED_P set anyway?

I was worried about that myself, but it didn't seem to happen.

combine is one of the places that deletes insns by turning them into
NOTE_INSN_DELETED.  I'm fairly sure what happened was the last set was
deleted by a previous combination.  Unfortunately I don't have a test
case for just this part of the patch.

> We could try changing use_crosses_set to do a walk of the insns in between.
> That's more expensive, but we may be able to get better results, esp. for
> MEMs (it looks like the function expects all MEMs to alias).

Well, really what ought to happen is reg_last_set should be updated
when we delete an insn it refers to.  I am surprised this doesn't
happen already.

> > 	* i386.md (*cc_noop_move, *pc_noop_move): Dummy insns to help
> > 	combine.
> 
> I'd prefer to fix combine...

Well, yes.  Ideally combine would notice when it had simplified to no
operation, recognizable or not, and delete the insn itself.  The
trouble is that combine just isn't set up to do that.  All the logic
to update the insn list assumes that that never happens.  I tried to
fix it and got lost in combine's internal data structures.

I almost think it would be easier to rewrite combine from scratch.  We
have a code flow graph and def-use chains now, but it doesn't know
about either.  It's also got massive code duplication of RTX
simplification logic...

zw


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