[mips] fix $gp restore bug

Adam Nemet anemet@caviumnetworks.com
Mon Sep 14 18:11:00 GMT 2009


Richard Sandiford writes:
> You're right that cprestores ought to be deleted when
> !mips_chosen_to_use_gp_p && optimize, but we don't generally delete
> them when optimisation is disabled.  So if we kept the original check,
> we would sometimes be left with loads from an uninitialised cprestore slot.
> As well as being untidy, I was worried that it might confuse valgrind-like
> analysis tools into thinking there was a bug in the program.  I also
> though it was odd to introduce real loads before we had introduced
> real stores.
> 
> This does show up as a failure in branch-8.c.

I see.

> However, I can see your point about it being confusing to have this one
> place where !mips_chosen_to_use_gp_p is not a reversible decision.
> And comments alone aren't really enough to compensate.
> 
> I think the confusion would remain whatever we call the function,
> so what do you think about the alternative below?  It instead has two
> state variables, one to decide whether the global pointer value needs
> to be initialised, and another to say whether pic_offset_table_rtx
> ought to be restored after being clobbered.  We can then document
> more easily that the latter variable has a very limited lifetime,
> whereas the former applies right to the end of compilation.

Yes, I think it works much better having separate flags.  Thanks!

Just another minor question.  In the "big comment" you reshuffled the order of
the points.  Previously they had been close to order in the pass pipeline.
Was this intentional?  I think the old was probably easier to follow.

Adam



More information about the Gcc-patches mailing list