This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: define "internal" visibility for i386
- From: Jan Hubicka <jh at suse dot cz>
- To: Richard Henderson <rth at redhat dot com>, gcc-patches at gcc dot gnu dot org, Ulrich Drepper <drepper at redhat dot com>
- Date: Sun, 3 Mar 2002 12:17:38 +0100
- Subject: Re: define "internal" visibility for i386
- References: <20020302210517.A30887@redhat.com>
> Gives a useful meaning to the processor-defined "internal"
> visibility for i386. Should be usable in e.g. glibc to
> eliminate some needless pic register loads without having
> to do whole-program analysis.
Shouldn't we also modify the call instruction pattern to call the
function directly w/o PIC tables?
(I see we will have to stay in the middle - call directly AND
force EBX to be load. Little bit nasty).
I've been also thinking about the EBX. I see that need for EBX to be fixed
during reload is possibilitiy that reload will introduce loads from constant
pool. But about the i386, that is very symetric about what can be load and
thus it is manageable to make visible all the loads before reload, perhaps we
can just rely on reload to not introduce any and unfix the register before
register allocation if no static memory storage references are present?
Honza