This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: gniibe@m17n.org: Re: target/4516: [SH] sh-unknown-linux-gnu: big jump table
- From: Joern Rennecke <joern dot rennecke at st dot com>
- To: rodrigc at gcc dot gnu dot org, gniibe at m17n dot org, gcc-patches at gcc dot gnu dot org,gcc-prs at gcc dot gnu dot org, jh at suse dot cz
- Date: Mon, 25 Feb 2002 22:04:24 +0000
- Subject: Re: gniibe@m17n.org: Re: target/4516: [SH] sh-unknown-linux-gnu: big jump table
- Organization: SuperH UK Ltd.
- Reply-to: joern dot rennecke at st dot com
(CASE_VECTOR_MODE): Always SImode. Starting from QImode (or
HImode) may result assembler error of "pcrel too far" (e.g.
compiling f/symbol.c). It's because barrier_align depends
on the mode.
This kind of information doesn't belong into the ChangeLog, but in the
explanation of the patch and comments in the source.
Anyways, the problem appears to be that alignments are computed only
once, while we would like them to be recomputed during each iteration
of shorten_branches.
Actually, it is a lot wors today than it was haf a year ago, since originally
the alignments were calculated with each invocation of shorten_branches, while
now they are computed only once; and the new code is not even suitable to
compute at shorten_branches time.
Mon Aug 20 01:44:50 CEST 2001 Jan Hubicka <jh@suse.cz>
* final.c (compute_alignments): New function.
(init_insn_lengths): Do not care label_align.
(LABEL_ALIGN_AFTER_BARRIER): Default to 1.
(LABEL_ALIGN_AFTER_BARRIER_MAX_SKIP): Default to 0.
(JUMP_ALIGN, JUMP_ALIGN_MAX_SKIP): New.
(shorted_branches): Realloc label_align array; do
not call init_insn_lengths; Do not care about loop alignments.
* output.h (compute_alignments): Declare.
* toplev.c (rest_of_compilation): Call compute_alignments.
* tm.texi (JUMP_ALIGN, JUMP_ALIGN_MAX_SKIP): Document.
This change makes also the impact of changing CASE_VECTOR_MODE to be SImode
worse,
since we don't pick up shortened modes at the second invocation of
shorten_branches.
Jan, what was the point of making the alignemnt computation depend on an
up-to-date
flowgraph?
--
--------------------------
SuperH
2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
T:+44 1454 462330