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: Reload inheritance and auto inc/dec


On Sep 12, 2000, Jeffrey A Law <law@cygnus.com> wrote:

>   In message <or1yyp6e03.fsf@guarana.lsd.ic.unicamp.br>you write:
>> --=-=-=
>> 
>> I've been investigating a reload problem that showed up while
>> compiling some code for SH.  Basically, the problem is that reload
>> didn't take advantage of inheritance for a pseudo used in an post_inc
>> memory reference, and, in a subsequence insn, ended up inheriting the
>> value of an out-dated register.

> First, right now we're generating incorrect code, right?  Any chance
> you'll be able to make a c-torture testcase out of the testcase you've
> got right now?

I'll try harder, but it's not going to be easy :-(

> Second, we have a missed optimization (didn't take advantage of inheritance
> for a pseudo ...)?

Right.

> Third, fixing #2 has the side effect of "fixing" #1?

> I would claim that while we want to fix the optimization, we also want to
> fix the underlying code generation bug.

My reasoning was that the underlying code generation bug was not an
unreasonable assumption.  The assumption is that, if the value of a
register is available with the value we need, we're going to use it.
So, the bug only showed up because there were two registers with the
value we needed, and that was only because the second use didn't
inherit the register from the first.

Now, on second thought, I think I can see situations in which this
might not be the case.  The register might be inherited for input
only, then modified and stored elsewhere, so it would no longer
contain the value of the intended pseudo, and inheriting it afterwards
would produce incorrect results. But the current inheritance code
wouldn't consider that register ineligible if it were modified by an
auto inc/dec.

>> (insn 220 218 221 (set (reg:QI 131)
>> (mem/s:QI (reg:SI 130) 0)) 89 {movqi_i} (insn_list 218 (nil))
>> (expr_list:REG_EQUIV (mem/s:QI (reg:SI 130) 0)
>> (nil)))
> This seems rather odd to me -- we've got a REG_EQUIV note which makes an
> equivalence between (reg:QI 131) and (mem:QI (reg:SI 130)).

[snip]

> However, that equivalence only holds during certain parts of the function
> because the value in (reg:SI 130) varies.

I think it's ok, (reg:SI 130) doesn't change during the life of the
pseudo.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

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