This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
RE: [BUG/PATCH 2.95.3] [V3 also] rs6000.c tests TREE_ASM_WRITTEN too early.
- To: 'David Edelsohn' <dje at watson dot ibm dot com>
- Subject: RE: [BUG/PATCH 2.95.3] [V3 also] rs6000.c tests TREE_ASM_WRITTEN too early.
- From: David Korn <dkorn at pixelpower dot com>
- Date: Fri, 12 Jan 2001 16:39:51 -0000
- Cc: 'Geoff Keating' <geoffk at redhat dot com>, davek-ml at ntlworld dot com, gcc-patches at gcc dot gnu dot org, mrs at windriver dot com
>David> Since none of this is under direct consideration for
>inclusion in the
>David> source tree ATM, I might just rely on the not-a-virtual
>test for vxworks
>David> ppc, but if there's a general solution that's a good
>engineering fix, I'd
>David> like to use that instead. Sorry for being such an
>irritating newbie!
>
> I had been testing the latest proposal, with rth's correction
>about PIC, for inclusion in the repository. Do you not want
>the partial improvement?
Yeah, of course I do, since it can only help. The trouble is that it's
not going to help very much in the real world if it never detects inlineable
functions....
What I *really* want is an even-better-improvement, which is why I thought
I'd ask round to see if anyone had any better ideas than me. You've all
got a good few years gcc-related experience on me, so I thought the odds
of that happening were fairly high, if there indeed was any better solution.
I suppose there might be a solution that would involve reaching up into
the inlining machinery, which I presume is the place that a) decides to
defer asm output of a function until the end of the compilation unit and b)
decides at the end whether to ignore it altogether. If those decisions are
made in one small area of the code, we could put stuff in there and be
fairly sure that if any future language decides to do something similar to
C++ virtual funcs, that's where the changes would need to be made, and we
could be fairly sure the code would stay correct and consistent. It
doesn't matter a great deal if we can't know whether or not a virtual func
will be emitted or not at the time when the deferred-output decision is
made, we could just assume that they are never
current_file_function_operands, but it would be a shame to lose the chance
to optimize calls to non virtual functions just because they get inlined
a few times.
DaveK
--
The Boulder Pledge: "Under no circumstances will I ever purchase anything
offered to me as the result of an unsolicited email message. Nor will I
forward chain letters, petitions, mass mailings, or virus warnings to large
numbers of others. This is my contribution to the survival of the online
community."
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
www.mimesweeper.com
**********************************************************************