This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: patch for 930513-1 on Darwin
- To: Dale Johannesen <dalej at apple dot com>
- Subject: Re: patch for 930513-1 on Darwin
- From: Geoff Keating <geoffk at geoffk dot org>
- Date: 05 Jun 2001 10:30:42 -0700
- CC: gcc-patches at gcc dot gnu dot org
- References: <200106051705.KAA12456@scv1.apple.com>
Dale Johannesen <dalej@apple.com> writes:
> On Thursday, May 31, 2001, at 06:03 PM, Dale Johannesen wrote:
> > On Thursday, May 31, 2001, at 05:52 PM, Richard Henderson wrote:
> >> On Thu, May 31, 2001 at 04:59:37PM -0700, dalej@apple.com wrote:
> >>> On Darwin, the required syntax for a function name is different
> >>> when you call it and when you pass its address, so the inliner
> >>> needs to change things to compensate.
> >>
> >> Err... no it doesn't. You can get into the same issue without
> >> inlining if you CSE a function address into a call pattern.
> >
> > Hmm, for some reason the function address doesn't seem to get put into
> > the call in this case, but you're right, obviously it should. I'll
> > check it out.
>
> This turns out to be interesting. With -static, a function address is
> pushed forward into a call in a case like this:
> int (*p) = foo;
> (*p)();
> It is combine, not cse, that does this, and it does so because combine
> has hardwired code that knows that (lo_sum (high foo) foo)==(foo).
>
> The usual case on Darwin, however, is pic, and there is no analogous
> code in combine for pic trees, so the substitution does not take place.
> Do you think it might be a good idea to add such code? Pic trees are
> different on different targets, of course, so it would have to be a
> macro. (I can also imagine that this substitution might not be a good
> idea with pic on some targets.)
Normally you set a REG_EQUIV note and this tells combine that p is &foo.
--
- Geoffrey Keating <geoffk@geoffk.org>