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: Problem in inheritance code


> The good news about Joern's work is I basically think it's done.   Jim and I
> have been reviewing and in some cases testing Joern's work throughout the
> development process (this work actually started about 6 months ago).
> 
> We've also been extracting out independent improvements and bugfixes along the
> way, much like we've been doing for your changes :-)

It seems to me that there are at least three independent parts in it: the
multi-insn-REG_EQUIV changes, the cleanup wrt. reg_equiv_address, and the
optional output reload parts.  Correct?

>   > There are some other places in choose_reload_regs/allocate_reload_reg which
>   > make the same assumption.  I'm wondering whether any of those could be
>   > incorrect as well.
> I suspect some are.  Though a brief glance at the existing uses tend to make
> me think it's more used to try and prefer using an existing spill reg over
> getting a new one (see the routines to find groups for example).  That may or
> may not be a reasonable heuristic once the localized spilling code is in place.

Probably most, if not all, cases are harmless, even if the test is wrong.  The
bug I reported is in the code that deals with a very special case: inheriting
a register, and then writing to it (which happens for an in-out operand with an
optional output reload).  That of course requires that nothing else is using
the register, but that requirement does not exist for simply inheriting a
register for the purpose of reading from it.

> I'm leaning towards getting Joern's patch in first.  It has fewer unknowns
> for performance issues.  That's largely because it is much less ambitious than
> your patch.
> 
> I do have the goal of having both in a local tree this weekend  (even if not
> committed) so that I can poke at them and lay to rest the performance concerns
> some folks have expressed with the local spilling code.

I'm aware of two performance issues: the used_spill_regs problem in reorg.c
(which should be settled now) and the fact that the spill cost calculations
need to be more global than they are with my patch.  Are you aware of any
other performance concerns?
 
> So, definitely send your last patch for the local spilling code.  If you've got
> diffs which apply both your patch and Joern's, you might send those to the
> list too.  If you don't have the combined patch, don't worry about it.

I sent the patch a few minutes ago.  I do have a combined patch, but that one
is at home unfortunately.  But they don't really conflict in many areas.

Bernd



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