This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 0/4] Alignment option enhancements
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: mliska at suse dot cz
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 16 Jul 2018 16:10:21 +0200
- Subject: Re: [PATCH 0/4] Alignment option enhancements
- References: <cover.1531730500.git.mliska@suse.cz>
On Mon, Jul 16, 2018 at 10:54 AM marxin <mliska@suse.cz> wrote:
>
> Hi.
>
> As you probably noticed, current trunk accepts extended format
> of -falign-FOO options.
> However there are some limitations that are addressed in the patchset:
>
> 1) E.g. align_labels_max_skip and align_labels_log are separate
> values and targets can override them via LABEL_ALIGN and
> LABEL_ALIGN_MAX_SKIP. If you take a look at code in final.c:
>
> if (max_log < log)
> {
> max_log = log;
> max_skip = targetm.asm_out.label_align_max_skip (label);
> }
>
> It improves alignment, but max_skip can be zero and then we end up
> with no alignment. Thus I see it saner to provide just a single hook
> and return align_flags class instance.
>
> 2) In final.c we mix label, jump and loop alignments. I believe when
> combining them together, one should do maximum and not rely on:
>
> #ifdef ASM_OUTPUT_MAX_SKIP_ALIGN
> ASM_OUTPUT_MAX_SKIP_ALIGN (file, align, max_skip);
> /* Above, we don't know whether a label, jump or loop
> alignment was used. Conservatively apply
> label subalignment, not jump or loop
> subalignment (they are almost always larger). */
>
> That's implemented in align_flags::max function. When combining
> for instance -falign-labels=1000 and -falign-jumps=2000, I hope
> using alignment of 2000 is the right choice.
It's documented that way btw.
>
> 3) I removed various align_* defines and use directly
> align_{*}.
>
> 4) I ported visium target to provide always secondary alignment of 8B.
> That's the same what x86_64 does and was factored out in previous commits
> I did.
>
> 5) Globally MAX_CODE_ALIGN is introduced.
>
> 6) Various coding styles are fixes in target code.
>
> 7) OPT_falign_* is not set with -Os. Then --help=common -Q reports proper values.
>
> I tested that on x86_64-linux-gnu and ppc64le-linux. And also I tested all targets
> that I touched, these should provide equal results.
>
> Martin
>
> marxin (4):
> Clean up of new format of -falign-FOO.
> Fix coding style of ASM_OUTPUT_ALIGN.
> Define MAX_CODE_ALIGN globally.
> Do not enable OPT_falign_* for -Os.
>
> gcc/align.h | 80 ++++++++++++
> gcc/common/config/i386/i386-common.c | 3 -
> gcc/config/alpha/alpha.c | 5 +-
> gcc/config/i386/att.h | 2 +-
> gcc/config/i386/cygming.h | 2 +-
> gcc/config/i386/gas.h | 2 +-
> gcc/config/i386/i386.c | 5 +-
> gcc/config/i386/x86-64.h | 2 +-
> gcc/config/iq2000/iq2000.h | 2 +-
> gcc/config/m32r/m32r.h | 3 +-
> gcc/config/m68k/m68k.c | 10 +-
> gcc/config/nds32/nds32.h | 9 +-
> gcc/config/pa/pa.h | 2 +-
> gcc/config/powerpcspe/powerpcspe.c | 18 +--
> gcc/config/rs6000/rs6000-protos.h | 2 +-
> gcc/config/rs6000/rs6000.c | 18 +--
> gcc/config/rx/rx-protos.h | 2 +-
> gcc/config/rx/rx.c | 59 +++++----
> gcc/config/rx/rx.h | 6 +-
> gcc/config/s390/s390.c | 9 +-
> gcc/config/sh/sh.c | 19 +--
> gcc/config/sparc/sol2.h | 2 +-
> gcc/config/sparc/sparc.h | 2 +-
> gcc/config/spu/spu.c | 6 +-
> gcc/config/spu/spu.h | 2 +-
> gcc/config/visium/visium.c | 2 +-
> gcc/config/visium/visium.h | 17 +--
> gcc/coretypes.h | 1 +
> gcc/doc/tm.texi | 24 ----
> gcc/doc/tm.texi.in | 8 --
> gcc/final.c | 189 ++++++++-------------------
> gcc/flags.h | 38 +-----
> gcc/opts.c | 12 +-
> gcc/output.h | 6 +-
> gcc/system.h | 2 -
> gcc/target.def | 40 ------
> gcc/targhooks.h | 4 -
> gcc/toplev.c | 44 ++-----
> gcc/varasm.c | 14 +-
> 39 files changed, 262 insertions(+), 411 deletions(-)
> create mode 100644 gcc/align.h
>
> --
> 2.18.0
>