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: Jan Hubicka <jh at suse dot cz>
- To: Joern Rennecke <joern dot rennecke at st dot com>
- Cc: 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: Tue, 26 Feb 2002 09:29:16 +0100
- Subject: Re: gniibe@m17n.org: Re: target/4516: [SH] sh-unknown-linux-gnu: big jump table
- References: <3C7AB4E8.A161C64B@st.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?
Yes, I need flowgraph and profile info in order to set up the alignments. It
should not be dificult to recompute alignment of case vectors in
shorten_branches in case it depends on the status of it (I didn't expected
something like that to be possible)
Honza
>
> --
> --------------------------
> SuperH
> 2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
> T:+44 1454 462330