* ColdFire submission
@ 2007-01-10 10:30 Richard Sandiford
2007-01-10 10:31 ` [ColdFire 1/63] Retabulate TARGET_CPU_CPP_BUILTINS Richard Sandiford
2007-01-10 22:58 ` ColdFire submission Steven Bosscher
0 siblings, 2 replies; 280+ messages in thread
From: Richard Sandiford @ 2007-01-10 10:30 UTC (permalink / raw)
To: gcc-patches
I'm about to submit the ColdFire 4.3 project:
http://gcc.gnu.org/wiki/Coldfire_changes
As usual with this sort of thing, a single patch would be too big
to review as a unit. I've therefore tried to split it into smaller,
more managable, pieces. There ended up being 63 in all.
It isn't really feasible to run regression tests for each individual
patch, as it would take an order of months, and mainline would have
changed a great deal by the time I'd finished. I therefore ran some
simple compile-only tests for the individual patches and did the
main testing on the series as a whole.
Specifically, to test the patches individually, I compiled a
baseline xgcc and cc1 for the following targets:
m68k-aout m68k-coff m68020-unknown-elf m68k-elf
m68010-unknown-netbsdelf m68k-netbsdelf m68k-openbsd
m68k-uclinux m68k-linux m68k-rtems
and saved the make logs. Then, for each patch in the series,
I built the tools again and compared the new make logs with the
last ones. I checked these diffs to make sure there were no
unexpected changes.
To test the series as a whole, I ran tests for these configuration
and option combinations:
m68k-linux-gnu -mcpu=5485
m68k-uclinux -mcpu=5329{,-msep-data,-mid-shared-library}
m68k-elf -mcpu=5208
These tests weren't regression tests because the support is new.
However, the results were as expected, and tie in with those for
the original 4.1 sources.
There are some target-independent changes, so I bootstrapped and
regression-tested the series on x86_64-linux-gnu. One of the
patches also steals code from MIPS; I'll describe the MIPS testing
when I get to that patch.
CodeSourcery don't have access to 680x0 hardware, so I didn't do
normal regression tests on 680x0 systems. However, as a sanity check,
I compiled gcc.c-torture, gcc.dg and g++.dg for the above targets
using the options:
-O0 -O2 -msep-data -mid-shared-library -mpcrel -fpic -fPIC
-O/-m68000 -O/-m68020 -O/-m68020-40 -O/-m68020-60
-O/-m68040 -O/-m68060 -O/-mcpu32 -O/-m68881
Not all these options make sense for all targets, but it was easier to
automate the test this way. I then compared the logs for the unpatched
compiler with those for the patched compiler, and there seemed to be no
new build failures. I also spot-checked some of the assembly code
differences. Those that I saw seemed benign.
Sorry for the upcoming deluge...
Richard
^ permalink raw reply [flat|nested] 280+ messages in thread* [ColdFire 1/63] Retabulate TARGET_CPU_CPP_BUILTINS 2007-01-10 10:30 ColdFire submission Richard Sandiford @ 2007-01-10 10:31 ` Richard Sandiford 2007-01-10 10:33 ` [ColdFire 2/63] Use TUNE_* macros instead of TARGET_* macros Richard Sandiford 2007-01-10 17:47 ` [ColdFire 1/63] Retabulate TARGET_CPU_CPP_BUILTINS Jeffrey Law 2007-01-10 22:58 ` ColdFire submission Steven Bosscher 1 sibling, 2 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 10:31 UTC (permalink / raw) To: gcc-patches Some of the later patches add lines to TARGET_CPU_CPP_BUITINS that stretch beyond the current backslash column. This patch simply makes room for them by moving the column to the right. The patch is obvious if the later patches are OK, but I'm posting it separately for ease of review. Richard gcc/ * config/m68k/m68k.h (TARGET_CPU_CPP_BUILTINS): Increase amount of tabbing before backslashes. Index: gcc/config/m68k/m68k.h =================================================================== --- gcc/config/m68k/m68k.h 2007-01-09 15:01:43.000000000 +0000 +++ gcc/config/m68k/m68k.h 2007-01-09 15:01:44.000000000 +0000 @@ -35,70 +35,70 @@ the Free Software Foundation; either ver /* Note that some other tm.h files include this one and then override many of the definitions that relate to assembler syntax. */ -#define TARGET_CPU_CPP_BUILTINS() \ - do \ - { \ - builtin_define ("__m68k__"); \ - builtin_define_std ("mc68000"); \ - if (TARGET_68040_ONLY) \ - { \ - if (TARGET_68060) \ - builtin_define_std ("mc68060"); \ - else \ - builtin_define_std ("mc68040"); \ - } \ - else if (TARGET_68060) /* -m68020-60 */ \ - { \ - builtin_define_std ("mc68060"); \ - builtin_define_std ("mc68040"); \ - builtin_define_std ("mc68030"); \ - builtin_define_std ("mc68020"); \ - } \ - else if (TARGET_68040) /* -m68020-40 */ \ - { \ - builtin_define_std ("mc68040"); \ - builtin_define_std ("mc68030"); \ - builtin_define_std ("mc68020"); \ - } \ - else if (TARGET_68030) \ - builtin_define_std ("mc68030"); \ - else if (TARGET_68020) \ - builtin_define_std ("mc68020"); \ - if (TARGET_68881) \ - builtin_define ("__HAVE_68881__"); \ - if (TARGET_CPU32) \ - { \ - builtin_define_std ("mc68332"); \ - builtin_define_std ("mcpu32"); \ - } \ - if (TARGET_COLDFIRE) \ - builtin_define ("__mcoldfire__"); \ - if (TARGET_5200) \ - builtin_define ("__mcf5200__"); \ - if (TARGET_528x) \ - { \ - builtin_define ("__mcf528x__"); \ - builtin_define ("__mcf5200__"); \ - } \ - if (TARGET_CFV3) \ - { \ - builtin_define ("__mcf5300__"); \ - builtin_define ("__mcf5307__"); \ - } \ - if (TARGET_CFV4) \ - { \ - builtin_define ("__mcf5400__"); \ - builtin_define ("__mcf5407__"); \ - } \ - if (TARGET_CFV4E) \ - { \ - builtin_define ("__mcfv4e__"); \ - } \ - if (TARGET_CF_HWDIV) \ - builtin_define ("__mcfhwdiv__"); \ - builtin_assert ("cpu=m68k"); \ - builtin_assert ("machine=m68k"); \ - } \ +#define TARGET_CPU_CPP_BUILTINS() \ + do \ + { \ + builtin_define ("__m68k__"); \ + builtin_define_std ("mc68000"); \ + if (TARGET_68040_ONLY) \ + { \ + if (TARGET_68060) \ + builtin_define_std ("mc68060"); \ + else \ + builtin_define_std ("mc68040"); \ + } \ + else if (TARGET_68060) /* -m68020-60 */ \ + { \ + builtin_define_std ("mc68060"); \ + builtin_define_std ("mc68040"); \ + builtin_define_std ("mc68030"); \ + builtin_define_std ("mc68020"); \ + } \ + else if (TARGET_68040) /* -m68020-40 */ \ + { \ + builtin_define_std ("mc68040"); \ + builtin_define_std ("mc68030"); \ + builtin_define_std ("mc68020"); \ + } \ + else if (TARGET_68030) \ + builtin_define_std ("mc68030"); \ + else if (TARGET_68020) \ + builtin_define_std ("mc68020"); \ + if (TARGET_68881) \ + builtin_define ("__HAVE_68881__"); \ + if (TARGET_CPU32) \ + { \ + builtin_define_std ("mc68332"); \ + builtin_define_std ("mcpu32"); \ + } \ + if (TARGET_COLDFIRE) \ + builtin_define ("__mcoldfire__"); \ + if (TARGET_5200) \ + builtin_define ("__mcf5200__"); \ + if (TARGET_528x) \ + { \ + builtin_define ("__mcf528x__"); \ + builtin_define ("__mcf5200__"); \ + } \ + if (TARGET_CFV3) \ + { \ + builtin_define ("__mcf5300__"); \ + builtin_define ("__mcf5307__"); \ + } \ + if (TARGET_CFV4) \ + { \ + builtin_define ("__mcf5400__"); \ + builtin_define ("__mcf5407__"); \ + } \ + if (TARGET_CFV4E) \ + { \ + builtin_define ("__mcfv4e__"); \ + } \ + if (TARGET_CF_HWDIV) \ + builtin_define ("__mcfhwdiv__"); \ + builtin_assert ("cpu=m68k"); \ + builtin_assert ("machine=m68k"); \ + } \ while (0) /* Classify the groups of pseudo-ops used to assemble QI, HI and SI ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 2/63] Use TUNE_* macros instead of TARGET_* macros 2007-01-10 10:31 ` [ColdFire 1/63] Retabulate TARGET_CPU_CPP_BUILTINS Richard Sandiford @ 2007-01-10 10:33 ` Richard Sandiford 2007-01-10 10:34 ` [ColdFire 3/63] Add TUNE_68040_60 Richard Sandiford ` (2 more replies) 2007-01-10 17:47 ` [ColdFire 1/63] Retabulate TARGET_CPU_CPP_BUILTINS Jeffrey Law 1 sibling, 3 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 10:33 UTC (permalink / raw) To: gcc-patches The current m68k TARGET_* macros are confusing. Some of them (like TARGET_68020 and TARGET_68040_ONLY) control the target ISA while others (like TARGET_68040 and TARGET_68060) control tuning. Other backends have standardised on TARGET_* for ISA selection and TUNE_* for tuning control. This patch makes the same distinction for m68k. There should be no behavioural changes. Later patches in the series get rid of the old tuning-related TARGET_* macros themselves; this patch simply adds TUNE_* wrappers for them. Later patches also add more TUNE_* macros and an -mtune command-line option. Richard gcc/ 200x-xx-xx Julian Brown <julian@codesourcery.com> Richard Sandiford <richard@codesourcery.com> * config/m68k/m68k.h (TARGET_CPU_CPP_BUILTINS): Use TUNE_68030 instead of TARGET_68030, TUNE_68040 instead of TARGET_68040, TUNE_68060 instead of TARGET_68060 and TUNE_CPU32 instead of TARGET_CPU32. (TARGET_CPU32): Rename to... (TUNE_CPU32): ...this. (TUNE_68000_10, TUNE_68030, TUNE_68040, TUNE_68060) (TUNE_CFV2): New macros. * config/m68k/netbsd-elf.h (LONG_DOUBLE_TYPE_SIZE): Simplify; remove conditions that are implied by TARGET_68020. * config/m68k/m68k.c (m68k_output_function_prologue): Use TUNE_68040 instead of TARGET_68040 and TUNE_CPU32 instead of TARGET_CPU32. (m68k_output_function_epilogue): Likewise. (m68k_rtx_costs): Likewise. Use TUNE_68060 instead of TARGET_68060 and TUNE_CFV2 instead of TARGET_5200. Use TUNE_68000_10 instead of "!TARGET_68020 && !TARGET_COLDFIRE" to choose between 68000 and non-68000 timings. Refactor multiplication and division costs. (output_addsi3): Use TUNE_68040 instead of TARGET_68040 and TUNE_CPU32 instead of TARGET_CPU32. (standard_68881_constant_p): Use TUNE_68040 instead of TARGET_68040 and TUNE_68060 instead of TARGET_68060. * config/m68k/m68k.md: Use TUNE_68040 instead of TARGET_68040, TUNE_68060 instead of TARGET_68060, and TUNE_CPU32 instead of TARGET_CPU32. (movsi_const0): Use TUNE_68000_10 rather than "!TARGET_68020 && !TARGET_COLDFIRE" to choose between moveq and clr. Likewise in the unnamed movsf pattern. (ashlsi_17_24, lshrsi_17_24): Guard with TUNE_68000_10 rather than "!TARGET_68020 && !TARGET_COLDFIRE". Likewise the unnamed ashiftrt pattern. Index: gcc/config/m68k/m68k.h =================================================================== --- gcc/config/m68k/m68k.h 2007-01-09 15:01:44.000000000 +0000 +++ gcc/config/m68k/m68k.h 2007-01-09 15:01:45.000000000 +0000 @@ -42,31 +42,31 @@ #define TARGET_CPU_CPP_BUILTINS() \ builtin_define_std ("mc68000"); \ if (TARGET_68040_ONLY) \ { \ - if (TARGET_68060) \ + if (TUNE_68060) \ builtin_define_std ("mc68060"); \ else \ builtin_define_std ("mc68040"); \ } \ - else if (TARGET_68060) /* -m68020-60 */ \ + else if (TUNE_68060) /* -m68020-60 */ \ { \ builtin_define_std ("mc68060"); \ builtin_define_std ("mc68040"); \ builtin_define_std ("mc68030"); \ builtin_define_std ("mc68020"); \ } \ - else if (TARGET_68040) /* -m68020-40 */ \ + else if (TUNE_68040) /* -m68020-40 */ \ { \ builtin_define_std ("mc68040"); \ builtin_define_std ("mc68030"); \ builtin_define_std ("mc68020"); \ } \ - else if (TARGET_68030) \ + else if (TUNE_68030) \ builtin_define_std ("mc68030"); \ else if (TARGET_68020) \ builtin_define_std ("mc68020"); \ if (TARGET_68881) \ builtin_define ("__HAVE_68881__"); \ - if (TARGET_CPU32) \ + if (TUNE_CPU32) \ { \ builtin_define_std ("mc68332"); \ builtin_define_std ("mcpu32"); \ @@ -113,7 +113,7 @@ #define INT_OP_GROUP INT_OP_DOT_WORD /* Compile for a CPU32. A 68020 without bitfields is a good heuristic for a CPU32. */ -#define TARGET_CPU32 (TARGET_68020 && !TARGET_BITFIELD) +#define TUNE_CPU32 (TARGET_68020 && !TARGET_BITFIELD) /* Is the target a ColdFire? */ #define MASK_COLDFIRE \ @@ -126,6 +126,11 @@ #define TARGET_HARD_FLOAT (TARGET_68881 /* Size (in bytes) of FPU registers. */ #define TARGET_FP_REG_SIZE (TARGET_COLDFIRE ? 8 : 12) +#define TUNE_68000_10 (!TARGET_68020 && !TARGET_COLDFIRE) +#define TUNE_68030 TARGET_68030 +#define TUNE_68040 TARGET_68040 +#define TUNE_68060 TARGET_68060 +#define TUNE_CFV2 TARGET_5200 #define OVERRIDE_OPTIONS override_options() Index: gcc/config/m68k/netbsd-elf.h =================================================================== --- gcc/config/m68k/netbsd-elf.h 2007-01-09 15:01:43.000000000 +0000 +++ gcc/config/m68k/netbsd-elf.h 2007-01-09 15:01:45.000000000 +0000 @@ -41,9 +41,7 @@ #define TARGET_DEFAULT TARGET_CPU_DEFAUL /* Don't try using XFmode on the 68010. */ #undef LONG_DOUBLE_TYPE_SIZE -#define LONG_DOUBLE_TYPE_SIZE \ - ((TARGET_68020 || TARGET_68040 || TARGET_68040_ONLY || \ - TARGET_68060) ? 80 : 64) +#define LONG_DOUBLE_TYPE_SIZE (TARGET_68020 ? 80 : 64) #ifdef __mc68010__ #define LIBGCC2_LONG_DOUBLE_TYPE_SIZE 64 Index: gcc/config/m68k/m68k.c =================================================================== --- gcc/config/m68k/m68k.c 2007-01-09 15:01:43.000000000 +0000 +++ gcc/config/m68k/m68k.c 2007-01-09 15:01:45.000000000 +0000 @@ -550,7 +550,7 @@ m68k_output_function_prologue (FILE *str if (frame_pointer_needed) { - if (current_frame.size == 0 && TARGET_68040) + if (current_frame.size == 0 && TUNE_68040) /* on the 68040, pea + move is faster than link.w 0 */ fprintf (stream, (MOTOROLA ? "\tpea (%s)\n\tmove.l %s,%s\n" @@ -584,14 +584,14 @@ m68k_output_function_prologue (FILE *str asm_fprintf (stream, "\tsubq" ASM_DOT "l %I%wd,%Rsp\n", fsize_with_regs); } - else if (fsize_with_regs <= 16 && TARGET_CPU32) + else if (fsize_with_regs <= 16 && TUNE_CPU32) /* On the CPU32 it is faster to use two subqw instructions to subtract a small integer (8 < N <= 16) to a register. */ asm_fprintf (stream, "\tsubq" ASM_DOT "w %I8,%Rsp\n" "\tsubq" ASM_DOT "w %I%wd,%Rsp\n", fsize_with_regs - 8); - else if (TARGET_68040) + else if (TUNE_68040) /* Adding negative number is faster on the 68040. */ asm_fprintf (stream, "\tadd" ASM_DOT "w %I%wd,%Rsp\n", -fsize_with_regs); @@ -1054,7 +1054,7 @@ m68k_output_function_epilogue (FILE *str asm_fprintf (stream, "\taddq" ASM_DOT "l %I%wd,%Rsp\n", fsize_with_regs); } - else if (fsize_with_regs <= 16 && TARGET_CPU32) + else if (fsize_with_regs <= 16 && TUNE_CPU32) { /* On the CPU32 it is faster to use two addqw instructions to add a small integer (8 < N <= 16) to a register. */ @@ -1065,7 +1065,7 @@ m68k_output_function_epilogue (FILE *str } else if (fsize_with_regs < 0x8000) { - if (TARGET_68040) + if (TUNE_68040) asm_fprintf (stream, "\tadd" ASM_DOT "w %I%wd,%Rsp\n", fsize_with_regs); else @@ -1634,12 +1634,21 @@ m68k_rtx_costs (rtx x, int code, int out sometimes move insns are needed. */ /* div?.w is relatively cheaper on 68000 counted in COSTS_N_INSNS terms. */ -#define MULL_COST (TARGET_68060 ? 2 : TARGET_68040 ? 5 \ - : (TARGET_COLDFIRE && !TARGET_5200) ? 3 \ - : TARGET_COLDFIRE ? 10 : 13) -#define MULW_COST (TARGET_68060 ? 2 : TARGET_68040 ? 3 : TARGET_68020 ? 8 \ - : (TARGET_COLDFIRE && !TARGET_5200) ? 2 : 5) -#define DIVW_COST (TARGET_68020 ? 27 : TARGET_CF_HWDIV ? 11 : 12) +#define MULL_COST \ + (TUNE_68060 ? 2 \ + : TUNE_68040 ? 5 \ + : TUNE_CFV2 ? 10 \ + : TARGET_COLDFIRE ? 3 : 13) + +#define MULW_COST \ + (TUNE_68060 ? 2 \ + : TUNE_68040 ? 3 \ + : TUNE_68000_10 || TUNE_CFV2 ? 5 \ + : TARGET_COLDFIRE ? 2 : 8) + +#define DIVW_COST \ + (TARGET_CF_HWDIV ? 11 \ + : TUNE_68000_10 || TARGET_COLDFIRE ? 12 : 27) case PLUS: /* An lea costs about three times as much as a simple add. */ @@ -1661,12 +1670,12 @@ #define DIVW_COST (TARGET_68020 ? 27 : T case ASHIFT: case ASHIFTRT: case LSHIFTRT: - if (TARGET_68060) + if (TUNE_68060) { *total = COSTS_N_INSNS(1); return true; } - if (! TARGET_68020 && ! TARGET_COLDFIRE) + if (TUNE_68000_10) { if (GET_CODE (XEXP (x, 1)) == CONST_INT) { @@ -2560,7 +2569,7 @@ output_addsi3 (rtx *operands) /* On the CPU32 it is faster to use two addql instructions to add a small integer (8 < N <= 16) to a register. Likewise for subql. */ - if (TARGET_CPU32 && REG_P (operands[0])) + if (TUNE_CPU32 && REG_P (operands[0])) { if (INTVAL (operands[2]) > 8 && INTVAL (operands[2]) <= 16) @@ -2579,7 +2588,7 @@ output_addsi3 (rtx *operands) && INTVAL (operands[2]) >= -0x8000 && INTVAL (operands[2]) < 0x8000) { - if (TARGET_68040) + if (TUNE_68040) return "add%.w %2,%0"; else return MOTOROLA ? "lea (%c2,%0),%0" : "lea %0@(%c2),%0"; @@ -2780,7 +2789,7 @@ standard_68881_constant_p (rtx x) /* fmovecr must be emulated on the 68040 and 68060, so it shouldn't be used at all on those chips. */ - if (TARGET_68040 || TARGET_68060) + if (TUNE_68040 || TUNE_68060) return 0; if (! inited_68881_table) Index: gcc/config/m68k/m68k.md =================================================================== --- gcc/config/m68k/m68k.md 2007-01-09 15:01:43.000000000 +0000 +++ gcc/config/m68k/m68k.md 2007-01-09 15:01:45.000000000 +0000 @@ -82,7 +82,7 @@ ;;- be emulated in software by the OS. It is faster to avoid these ;;- instructions and issue a library call rather than trapping into ;;- the kernel. The affected instructions are fintrz and fscale. The -;;- TARGET_68040 flag turns the use of the opcodes off. +;;- TUNE_68040 flag turns the use of the opcodes off. ;;- The '040 also implements a set of new floating-point instructions ;;- which specify the rounding precision in the opcode. This finally @@ -104,7 +104,7 @@ ;;- instructions and issue a library call rather than trapping into ;;- the kernel. The affected instructions are: divs.l <ea>,Dr:Dq; ;;- divu.l <ea>,Dr:Dq; muls.l <ea>,Dr:Dq; mulu.l <ea>,Dr:Dq; and -;;- fscale. The TARGET_68060 flag turns the use of the opcodes off. +;;- fscale. The TUNE_68060 flag turns the use of the opcodes off. ;;- Some of these insn's are composites of several m68000 op codes. ;;- The assembler (or final @@??) insures that the appropriate one is @@ -618,13 +618,13 @@ (define_insn "movsi_const0" if (ADDRESS_REG_P (operands[0])) { /* On the '040, 'subl an,an' takes 2 clocks while lea takes only 1 */ - if (!TARGET_68040 && !TARGET_68060) + if (!TUNE_68040 && !TUNE_68060) return "sub%.l %0,%0"; else return MOTOROLA ? "lea 0.w,%0" : "lea 0:w,%0"; } /* moveq is faster on the 68000. */ - if (DATA_REG_P (operands[0]) && (!TARGET_68020 && !TARGET_COLDFIRE)) + if (DATA_REG_P (operands[0]) && TUNE_68000_10) return "moveq #0,%0"; return "clr%.l %0"; }) @@ -846,16 +846,14 @@ (define_insn "" if (ADDRESS_REG_P (operands[0])) { /* On the '040, 'subl an,an' takes 2 clocks while lea takes only 1 */ - if (!TARGET_68040 && !TARGET_68060) + if (!TUNE_68040 && !TUNE_68060) return "sub%.l %0,%0"; else return MOTOROLA ? "lea 0.w,%0" : "lea 0:w,%0"; } /* moveq is faster on the 68000. */ - if (DATA_REG_P (operands[0]) && !(TARGET_68020 || TARGET_COLDFIRE)) - { - return "moveq #0,%0"; - } + if (DATA_REG_P (operands[0]) && TUNE_68000_10) + return "moveq #0,%0"; return "clr%.l %0"; } return "move%.l %1,%0"; @@ -1760,7 +1758,7 @@ (define_insn "fix_truncdfsi2" (fix:SI (fix:DF (match_operand:DF 1 "register_operand" "f")))) (clobber (match_scratch:SI 2 "=d")) (clobber (match_scratch:SI 3 "=d"))] - "TARGET_68881 && TARGET_68040" + "TARGET_68881 && TUNE_68040" { CC_STATUS_INIT; return "fmovem%.l %!,%2\;moveq #16,%3\;or%.l %2,%3\;and%.w #-33,%3\;fmovem%.l %3,%!\;fmove%.l %1,%0\;fmovem%.l %2,%!"; @@ -1771,7 +1769,7 @@ (define_insn "fix_truncdfhi2" (fix:HI (fix:DF (match_operand:DF 1 "register_operand" "f")))) (clobber (match_scratch:SI 2 "=d")) (clobber (match_scratch:SI 3 "=d"))] - "TARGET_68881 && TARGET_68040" + "TARGET_68881 && TUNE_68040" { CC_STATUS_INIT; return "fmovem%.l %!,%2\;moveq #16,%3\;or%.l %2,%3\;and%.w #-33,%3\;fmovem%.l %3,%!\;fmove%.w %1,%0\;fmovem%.l %2,%!"; @@ -1782,7 +1780,7 @@ (define_insn "fix_truncdfqi2" (fix:QI (fix:DF (match_operand:DF 1 "register_operand" "f")))) (clobber (match_scratch:SI 2 "=d")) (clobber (match_scratch:SI 3 "=d"))] - "TARGET_68881 && TARGET_68040" + "TARGET_68881 && TUNE_68040" { CC_STATUS_INIT; return "fmovem%.l %!,%2\;moveq #16,%3\;or%.l %2,%3\;and%.w #-33,%3\;fmovem%.l %3,%!\;fmove%.b %1,%0\;fmovem%.l %2,%!"; @@ -1794,13 +1792,13 @@ (define_insn "fix_truncdfqi2" (define_expand "ftrunc<mode>2" [(set (match_operand:FP 0 "nonimmediate_operand" "") (fix:FP (match_operand:FP 1 "general_operand" "")))] - "TARGET_HARD_FLOAT && !TARGET_68040" + "TARGET_HARD_FLOAT && !TUNE_68040" "") (define_insn "ftrunc<mode>2_68881" [(set (match_operand:FP 0 "nonimmediate_operand" "=f") (fix:FP (match_operand:FP 1 "general_operand" "f<FP:dreg>m")))] - "TARGET_68881 && !TARGET_68040" + "TARGET_68881 && !TUNE_68040" { if (FP_REG_P (operands[1])) return "fintrz%.x %f1,%0"; @@ -2130,7 +2128,7 @@ (define_insn "addhi3" /* On the CPU32 it is faster to use two addqw instructions to add a small integer (8 < N <= 16) to a register. Likewise for subqw. */ - if (TARGET_CPU32 && REG_P (operands[0])) + if (TUNE_CPU32 && REG_P (operands[0])) { if (INTVAL (operands[2]) > 8 && INTVAL (operands[2]) <= 16) @@ -2145,7 +2143,7 @@ (define_insn "addhi3" return "subq%.w #8,%0\;subq%.w %2,%0"; } } - if (ADDRESS_REG_P (operands[0]) && !TARGET_68040) + if (ADDRESS_REG_P (operands[0]) && !TUNE_68040) return MOTOROLA ? "lea (%c2,%0),%0" : "lea %0@(%c2),%0"; } return "add%.w %2,%0"; @@ -2185,7 +2183,7 @@ (define_insn "" /* On the CPU32 it is faster to use two addqw instructions to add a small integer (8 < N <= 16) to a register. Likewise for subqw. */ - if (TARGET_CPU32 && REG_P (operands[0])) + if (TUNE_CPU32 && REG_P (operands[0])) { if (INTVAL (operands[1]) > 8 && INTVAL (operands[1]) <= 16) @@ -2200,7 +2198,7 @@ (define_insn "" return "subq%.w #8,%0\;subq%.w %1,%0"; } } - if (ADDRESS_REG_P (operands[0]) && !TARGET_68040) + if (ADDRESS_REG_P (operands[0]) && !TUNE_68040) return MOTOROLA ? "lea (%c1,%0),%0" : "lea %0@(%c1),%0"; } return "add%.w %1,%0"; @@ -2234,7 +2232,7 @@ (define_insn "" /* On the CPU32 it is faster to use two addqw instructions to add a small integer (8 < N <= 16) to a register. Likewise for subqw. */ - if (TARGET_CPU32 && REG_P (operands[0])) + if (TUNE_CPU32 && REG_P (operands[0])) { if (INTVAL (operands[1]) > 8 && INTVAL (operands[1]) <= 16) @@ -2249,7 +2247,7 @@ (define_insn "" return "subq%.w #8,%0\;subq%.w %1,%0"; } } - if (ADDRESS_REG_P (operands[0]) && !TARGET_68040) + if (ADDRESS_REG_P (operands[0]) && !TUNE_68040) return MOTOROLA ? "lea (%c1,%0),%0" : "lea %0@(%c1),%0"; } return "add%.w %1,%0"; @@ -2670,7 +2668,7 @@ (define_expand "umulsidi3" (truncate:SI (lshiftrt:DI (mult:DI (zero_extend:DI (match_dup 1)) (zero_extend:DI (match_dup 2))) (const_int 32))))])] - "TARGET_68020 && !TARGET_68060 && !TARGET_COLDFIRE" + "TARGET_68020 && !TUNE_68060 && !TARGET_COLDFIRE" "") (define_insn "" @@ -2681,7 +2679,7 @@ (define_insn "" (truncate:SI (lshiftrt:DI (mult:DI (zero_extend:DI (match_dup 1)) (zero_extend:DI (match_dup 2))) (const_int 32))))] - "TARGET_68020 && !TARGET_68060 && !TARGET_COLDFIRE" + "TARGET_68020 && !TUNE_68060 && !TARGET_COLDFIRE" "mulu%.l %2,%3:%0") ; Match immediate case. For 2.4 only match things < 2^31. @@ -2696,7 +2694,7 @@ (define_insn "" (truncate:SI (lshiftrt:DI (mult:DI (zero_extend:DI (match_dup 1)) (match_dup 2)) (const_int 32))))] - "TARGET_68020 && !TARGET_68060 && !TARGET_COLDFIRE + "TARGET_68020 && !TUNE_68060 && !TARGET_COLDFIRE && (unsigned) INTVAL (operands[2]) <= 0x7fffffff" "mulu%.l %2,%3:%0") @@ -2709,7 +2707,7 @@ (define_expand "mulsidi3" (truncate:SI (lshiftrt:DI (mult:DI (sign_extend:DI (match_dup 1)) (sign_extend:DI (match_dup 2))) (const_int 32))))])] - "TARGET_68020 && !TARGET_68060 && !TARGET_COLDFIRE" + "TARGET_68020 && !TUNE_68060 && !TARGET_COLDFIRE" "") (define_insn "" @@ -2720,7 +2718,7 @@ (define_insn "" (truncate:SI (lshiftrt:DI (mult:DI (sign_extend:DI (match_dup 1)) (sign_extend:DI (match_dup 2))) (const_int 32))))] - "TARGET_68020 && !TARGET_68060 && !TARGET_COLDFIRE" + "TARGET_68020 && !TUNE_68060 && !TARGET_COLDFIRE" "muls%.l %2,%3:%0") (define_insn "" @@ -2731,7 +2729,7 @@ (define_insn "" (truncate:SI (lshiftrt:DI (mult:DI (sign_extend:DI (match_dup 1)) (match_dup 2)) (const_int 32))))] - "TARGET_68020 && !TARGET_68060 && !TARGET_COLDFIRE" + "TARGET_68020 && !TUNE_68060 && !TARGET_COLDFIRE" "muls%.l %2,%3:%0") (define_expand "umulsi3_highpart" @@ -2743,7 +2741,7 @@ (define_expand "umulsi3_highpart" (zero_extend:DI (match_operand:SI 2 "general_operand" ""))) (const_int 32)))) (clobber (match_dup 3))])] - "TARGET_68020 && !TARGET_68060 && !TARGET_COLDFIRE" + "TARGET_68020 && !TUNE_68060 && !TARGET_COLDFIRE" { operands[3] = gen_reg_rtx (SImode); @@ -2767,7 +2765,7 @@ (define_insn "" (zero_extend:DI (match_operand:SI 3 "nonimmediate_operand" "dm"))) (const_int 32)))) (clobber (match_operand:SI 1 "register_operand" "=d"))] - "TARGET_68020 && !TARGET_68060 && !TARGET_COLDFIRE" + "TARGET_68020 && !TUNE_68060 && !TARGET_COLDFIRE" "mulu%.l %3,%0:%1") (define_insn "const_umulsi3_highpart" @@ -2778,7 +2776,7 @@ (define_insn "const_umulsi3_highpart" (match_operand:DI 3 "const_uint32_operand" "n")) (const_int 32)))) (clobber (match_operand:SI 1 "register_operand" "=d"))] - "TARGET_68020 && !TARGET_68060 && !TARGET_COLDFIRE" + "TARGET_68020 && !TUNE_68060 && !TARGET_COLDFIRE" "mulu%.l %3,%0:%1") (define_expand "smulsi3_highpart" @@ -2790,7 +2788,7 @@ (define_expand "smulsi3_highpart" (sign_extend:DI (match_operand:SI 2 "general_operand" ""))) (const_int 32)))) (clobber (match_dup 3))])] - "TARGET_68020 && !TARGET_68060 && !TARGET_COLDFIRE" + "TARGET_68020 && !TUNE_68060 && !TARGET_COLDFIRE" { operands[3] = gen_reg_rtx (SImode); if (GET_CODE (operands[2]) == CONST_INT) @@ -2810,7 +2808,7 @@ (define_insn "" (sign_extend:DI (match_operand:SI 3 "nonimmediate_operand" "dm"))) (const_int 32)))) (clobber (match_operand:SI 1 "register_operand" "=d"))] - "TARGET_68020 && !TARGET_68060 && !TARGET_COLDFIRE" + "TARGET_68020 && !TUNE_68060 && !TARGET_COLDFIRE" "muls%.l %3,%0:%1") (define_insn "const_smulsi3_highpart" @@ -2821,7 +2819,7 @@ (define_insn "const_smulsi3_highpart" (match_operand:DI 3 "const_sint32_operand" "n")) (const_int 32)))) (clobber (match_operand:SI 1 "register_operand" "=d"))] - "TARGET_68020 && !TARGET_68060 && !TARGET_COLDFIRE" + "TARGET_68020 && !TUNE_68060 && !TARGET_COLDFIRE" "muls%.l %3,%0:%1") (define_expand "mul<mode>3" @@ -2871,7 +2869,7 @@ (define_insn "muldf_68881" "TARGET_68881" { if (GET_CODE (operands[2]) == CONST_DOUBLE - && floating_exact_log2 (operands[2]) && !TARGET_68040 && !TARGET_68060) + && floating_exact_log2 (operands[2]) && !TUNE_68040 && !TUNE_68060) { int i = floating_exact_log2 (operands[2]); operands[2] = GEN_INT (i); @@ -4174,7 +4172,7 @@ (define_insn "ashlsi_16" [(set (match_operand:SI 0 "register_operand" "=d") (ashift:SI (match_operand:SI 1 "register_operand" "0") (const_int 16)))] - "!TARGET_68060" + "!TUNE_68060" { CC_STATUS_INIT; return "swap %0\;clr%.w %0"; @@ -4189,8 +4187,9 @@ (define_insn "ashlsi_17_24" [(set (match_operand:SI 0 "register_operand" "=d") (ashift:SI (match_operand:SI 1 "register_operand" "0") (match_operand:SI 2 "const_int_operand" "n")))] - "(! TARGET_68020 && !TARGET_COLDFIRE - && INTVAL (operands[2]) > 16 && INTVAL (operands[2]) <= 24)" + "TUNE_68000_10 + && INTVAL (operands[2]) > 16 + && INTVAL (operands[2]) <= 24" { CC_STATUS_INIT; @@ -4246,7 +4245,7 @@ (define_insn "ashrsi_16" [(set (match_operand:SI 0 "register_operand" "=d") (ashiftrt:SI (match_operand:SI 1 "register_operand" "0") (const_int 16)))] - "!TARGET_68060" + "!TUNE_68060" "swap %0\;ext%.l %0") ;; On the 68000, this makes faster code in a special case. @@ -4255,8 +4254,9 @@ (define_insn "" [(set (match_operand:SI 0 "register_operand" "=d") (ashiftrt:SI (match_operand:SI 1 "register_operand" "0") (match_operand:SI 2 "const_int_operand" "n")))] - "(! TARGET_68020 && !TARGET_COLDFIRE - && INTVAL (operands[2]) > 16 && INTVAL (operands[2]) <= 24)" + "TUNE_68000_10 + && INTVAL (operands[2]) > 16 + && INTVAL (operands[2]) <= 24" { operands[2] = GEN_INT (INTVAL (operands[2]) - 16); return "swap %0\;asr%.w %2,%0\;ext%.l %0"; @@ -4548,7 +4548,7 @@ (define_insn "lshrsi_16" [(set (match_operand:SI 0 "register_operand" "=d") (lshiftrt:SI (match_operand:SI 1 "register_operand" "0") (const_int 16)))] - "!TARGET_68060" + "!TUNE_68060" { CC_STATUS_INIT; return "clr%.w %0\;swap %0"; @@ -4560,8 +4560,9 @@ (define_insn "lshrsi_17_24" [(set (match_operand:SI 0 "register_operand" "=d") (lshiftrt:SI (match_operand:SI 1 "register_operand" "0") (match_operand:SI 2 "const_int_operand" "n")))] - "(! TARGET_68020 && !TARGET_COLDFIRE - && INTVAL (operands[2]) > 16 && INTVAL (operands[2]) <= 24)" + "TUNE_68000_10 + && INTVAL (operands[2]) > 16 + && INTVAL (operands[2]) <= 24" { /* I think lsr%.w sets the CC properly. */ operands[2] = GEN_INT (INTVAL (operands[2]) - 16); @@ -5201,7 +5202,7 @@ (define_expand "seq" (eq:QI (cc0) (const_int 0)))] "" { - if ((TARGET_68060 || TARGET_COLDFIRE_FPU) + if ((TUNE_68060 || TARGET_COLDFIRE_FPU) && m68k_last_compare_had_fp_operands) { m68k_last_compare_had_fp_operands = 0; @@ -5223,7 +5224,7 @@ (define_expand "sne" (ne:QI (cc0) (const_int 0)))] "" { - if ((TARGET_68060 || TARGET_COLDFIRE_FPU) + if ((TUNE_68060 || TARGET_COLDFIRE_FPU) && m68k_last_compare_had_fp_operands) { m68k_last_compare_had_fp_operands = 0; @@ -5245,7 +5246,7 @@ (define_expand "sgt" (gt:QI (cc0) (const_int 0)))] "" { - if ((TARGET_68060 || TARGET_COLDFIRE_FPU) + if ((TUNE_68060 || TARGET_COLDFIRE_FPU) && m68k_last_compare_had_fp_operands) { m68k_last_compare_had_fp_operands = 0; @@ -5282,7 +5283,7 @@ (define_expand "slt" (lt:QI (cc0) (const_int 0)))] "" { - if ((TARGET_68060 || TARGET_COLDFIRE_FPU) + if ((TUNE_68060 || TARGET_COLDFIRE_FPU) && m68k_last_compare_had_fp_operands) { m68k_last_compare_had_fp_operands = 0; @@ -5319,7 +5320,7 @@ (define_expand "sge" (ge:QI (cc0) (const_int 0)))] "" { - if ((TARGET_68060 || TARGET_COLDFIRE_FPU) + if ((TUNE_68060 || TARGET_COLDFIRE_FPU) && m68k_last_compare_had_fp_operands) { m68k_last_compare_had_fp_operands = 0; @@ -5356,7 +5357,7 @@ (define_expand "sle" (le:QI (cc0) (const_int 0)))] "" { - if ((TARGET_68060 || TARGET_COLDFIRE_FPU) + if ((TUNE_68060 || TARGET_COLDFIRE_FPU) && m68k_last_compare_had_fp_operands) { m68k_last_compare_had_fp_operands = 0; @@ -5391,7 +5392,7 @@ (define_insn "" (define_expand "sordered" [(set (match_operand:QI 0 "register_operand" "") (ordered:QI (cc0) (const_int 0)))] - "TARGET_68881 && !TARGET_68060" + "TARGET_68881 && !TUNE_68060" { gcc_assert (m68k_last_compare_had_fp_operands); m68k_last_compare_had_fp_operands = 0; @@ -5400,7 +5401,7 @@ (define_expand "sordered" (define_insn "*sordered_1" [(set (match_operand:QI 0 "register_operand" "=d") (ordered:QI (cc0) (const_int 0)))] - "TARGET_68881 && !TARGET_68060" + "TARGET_68881 && !TUNE_68060" { cc_status = cc_prev_status; return "fsor %0"; @@ -5409,7 +5410,7 @@ (define_insn "*sordered_1" (define_expand "sunordered" [(set (match_operand:QI 0 "register_operand" "") (unordered:QI (cc0) (const_int 0)))] - "TARGET_68881 && !TARGET_68060" + "TARGET_68881 && !TUNE_68060" { gcc_assert (m68k_last_compare_had_fp_operands); m68k_last_compare_had_fp_operands = 0; @@ -5418,7 +5419,7 @@ (define_expand "sunordered" (define_insn "*sunordered_1" [(set (match_operand:QI 0 "register_operand" "=d") (unordered:QI (cc0) (const_int 0)))] - "TARGET_68881 && !TARGET_68060" + "TARGET_68881 && !TUNE_68060" { cc_status = cc_prev_status; return "fsun %0"; @@ -5427,7 +5428,7 @@ (define_insn "*sunordered_1" (define_expand "suneq" [(set (match_operand:QI 0 "register_operand" "") (uneq:QI (cc0) (const_int 0)))] - "TARGET_68881 && !TARGET_68060" + "TARGET_68881 && !TUNE_68060" { gcc_assert (m68k_last_compare_had_fp_operands); m68k_last_compare_had_fp_operands = 0; @@ -5436,7 +5437,7 @@ (define_expand "suneq" (define_insn "*suneq_1" [(set (match_operand:QI 0 "register_operand" "=d") (uneq:QI (cc0) (const_int 0)))] - "TARGET_68881 && !TARGET_68060" + "TARGET_68881 && !TUNE_68060" { cc_status = cc_prev_status; return "fsueq %0"; @@ -5445,7 +5446,7 @@ (define_insn "*suneq_1" (define_expand "sunge" [(set (match_operand:QI 0 "register_operand" "") (unge:QI (cc0) (const_int 0)))] - "TARGET_68881 && !TARGET_68060" + "TARGET_68881 && !TUNE_68060" { gcc_assert (m68k_last_compare_had_fp_operands); m68k_last_compare_had_fp_operands = 0; @@ -5454,7 +5455,7 @@ (define_expand "sunge" (define_insn "*sunge_1" [(set (match_operand:QI 0 "register_operand" "=d") (unge:QI (cc0) (const_int 0)))] - "TARGET_68881 && !TARGET_68060" + "TARGET_68881 && !TUNE_68060" { cc_status = cc_prev_status; return "fsuge %0"; @@ -5463,7 +5464,7 @@ (define_insn "*sunge_1" (define_expand "sungt" [(set (match_operand:QI 0 "register_operand" "") (ungt:QI (cc0) (const_int 0)))] - "TARGET_68881 && !TARGET_68060" + "TARGET_68881 && !TUNE_68060" { gcc_assert (m68k_last_compare_had_fp_operands); m68k_last_compare_had_fp_operands = 0; @@ -5472,7 +5473,7 @@ (define_expand "sungt" (define_insn "*sungt_1" [(set (match_operand:QI 0 "register_operand" "=d") (ungt:QI (cc0) (const_int 0)))] - "TARGET_68881 && !TARGET_68060" + "TARGET_68881 && !TUNE_68060" { cc_status = cc_prev_status; return "fsugt %0"; @@ -5481,7 +5482,7 @@ (define_insn "*sungt_1" (define_expand "sunle" [(set (match_operand:QI 0 "register_operand" "") (unle:QI (cc0) (const_int 0)))] - "TARGET_68881 && !TARGET_68060" + "TARGET_68881 && !TUNE_68060" { gcc_assert (m68k_last_compare_had_fp_operands); m68k_last_compare_had_fp_operands = 0; @@ -5490,7 +5491,7 @@ (define_expand "sunle" (define_insn "*sunle_1" [(set (match_operand:QI 0 "register_operand" "=d") (unle:QI (cc0) (const_int 0)))] - "TARGET_68881 && !TARGET_68060" + "TARGET_68881 && !TUNE_68060" { cc_status = cc_prev_status; return "fsule %0"; @@ -5499,7 +5500,7 @@ (define_insn "*sunle_1" (define_expand "sunlt" [(set (match_operand:QI 0 "register_operand" "") (unlt:QI (cc0) (const_int 0)))] - "TARGET_68881 && !TARGET_68060" + "TARGET_68881 && !TUNE_68060" { gcc_assert (m68k_last_compare_had_fp_operands); m68k_last_compare_had_fp_operands = 0; @@ -5508,7 +5509,7 @@ (define_expand "sunlt" (define_insn "*sunlt_1" [(set (match_operand:QI 0 "register_operand" "=d") (unlt:QI (cc0) (const_int 0)))] - "TARGET_68881 && !TARGET_68060" + "TARGET_68881 && !TUNE_68060" { cc_status = cc_prev_status; return "fsult %0"; @@ -5517,7 +5518,7 @@ (define_insn "*sunlt_1" (define_expand "sltgt" [(set (match_operand:QI 0 "register_operand" "") (ltgt:QI (cc0) (const_int 0)))] - "TARGET_68881 && !TARGET_68060" + "TARGET_68881 && !TUNE_68060" { gcc_assert (m68k_last_compare_had_fp_operands); m68k_last_compare_had_fp_operands = 0; @@ -5526,7 +5527,7 @@ (define_expand "sltgt" (define_insn "*sltgt_1" [(set (match_operand:QI 0 "register_operand" "=d") (ltgt:QI (cc0) (const_int 0)))] - "TARGET_68881 && !TARGET_68060" + "TARGET_68881 && !TUNE_68060" { cc_status = cc_prev_status; return "fsogl %0"; @@ -5535,7 +5536,7 @@ (define_insn "*sltgt_1" (define_insn "*fsogt_1" [(set (match_operand:QI 0 "register_operand" "=d") (not:QI (unle:QI (cc0) (const_int 0))))] - "TARGET_68881 && !TARGET_68060" + "TARGET_68881 && !TUNE_68060" { cc_status = cc_prev_status; return "fsogt %0"; @@ -5544,7 +5545,7 @@ (define_insn "*fsogt_1" (define_insn "*fsoge_1" [(set (match_operand:QI 0 "register_operand" "=d") (not:QI (unlt:QI (cc0) (const_int 0))))] - "TARGET_68881 && !TARGET_68060" + "TARGET_68881 && !TUNE_68060" { cc_status = cc_prev_status; return "fsoge %0"; @@ -5553,7 +5554,7 @@ (define_insn "*fsoge_1" (define_insn "*fsolt_1" [(set (match_operand:QI 0 "register_operand" "=d") (not:QI (unge:QI (cc0) (const_int 0))))] - "TARGET_68881 && !TARGET_68060" + "TARGET_68881 && !TUNE_68060" { cc_status = cc_prev_status; return "fsolt %0"; @@ -5562,7 +5563,7 @@ (define_insn "*fsolt_1" (define_insn "*fsole_1" [(set (match_operand:QI 0 "register_operand" "=d") (not:QI (ungt:QI (cc0) (const_int 0))))] - "TARGET_68881 && !TARGET_68060" + "TARGET_68881 && !TUNE_68060" { cc_status = cc_prev_status; return "fsole %0"; @@ -6625,14 +6626,14 @@ (define_peephole else output_asm_insn ("addq%.l %1,%0", xoperands); } - else if (TARGET_CPU32 && INTVAL (xoperands[1]) <= 16) + else if (TUNE_CPU32 && INTVAL (xoperands[1]) <= 16) { xoperands[1] = GEN_INT (INTVAL (xoperands[1]) - 8); output_asm_insn ("addq%.w #8,%0\;addq%.w %1,%0", xoperands); } else if (INTVAL (xoperands[1]) <= 0x7FFF) { - if (TARGET_68040) + if (TUNE_68040) output_asm_insn ("add%.w %1,%0", xoperands); else if (MOTOROLA) output_asm_insn ("lea (%c1,%0),%0", xoperands); @@ -6669,14 +6670,14 @@ (define_peephole else output_asm_insn ("addq%.l %1,%0", xoperands); } - else if (TARGET_CPU32 && INTVAL (xoperands[1]) <= 16) + else if (TUNE_CPU32 && INTVAL (xoperands[1]) <= 16) { xoperands[1] = GEN_INT (INTVAL (xoperands[1]) - 8); output_asm_insn ("addq%.w #8,%0\;addq%.w %1,%0", xoperands); } else if (INTVAL (xoperands[1]) <= 0x7FFF) { - if (TARGET_68040) + if (TUNE_68040) output_asm_insn ("add%.w %1,%0", xoperands); else if (MOTOROLA) output_asm_insn ("lea (%c1,%0),%0", xoperands); ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 3/63] Add TUNE_68040_60 2007-01-10 10:33 ` [ColdFire 2/63] Use TUNE_* macros instead of TARGET_* macros Richard Sandiford @ 2007-01-10 10:34 ` Richard Sandiford 2007-01-10 10:35 ` [ColdFire 4/63] TARGET_COLDFIRE_FPU vs. TARGET_CFV4E Richard Sandiford 2007-01-10 17:48 ` [ColdFire 3/63] Add TUNE_68040_60 Jeffrey Law 2007-01-10 17:47 ` [ColdFire 2/63] Use TUNE_* macros instead of TARGET_* macros Jeffrey Law 2007-01-15 17:16 ` Roman Zippel 2 siblings, 2 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 10:34 UTC (permalink / raw) To: gcc-patches Some bits of tuning code apply to both the 68040 and 68060. This patch simply adds a single macro for that, along the lines of the TUNE_68000_10 macro added in the last patch. Richard gcc/ 200x-xx-xx Julian Brown <julian@codesourcery.com> * config/m68k/m68k.h (TUNE_68040_60): New macro. * config/m68k/m68k.c (standard_68881_constant_p): Use it. * config/m68k/m68k.md: Likewise. Index: gcc/config/m68k/m68k.h =================================================================== --- gcc/config/m68k/m68k.h 2007-01-09 15:01:45.000000000 +0000 +++ gcc/config/m68k/m68k.h 2007-01-09 15:01:45.000000000 +0000 @@ -130,6 +130,7 @@ #define TUNE_68000_10 (!TARGET_68020 && #define TUNE_68030 TARGET_68030 #define TUNE_68040 TARGET_68040 #define TUNE_68060 TARGET_68060 +#define TUNE_68040_60 (TUNE_68040 || TUNE_68060) #define TUNE_CFV2 TARGET_5200 #define OVERRIDE_OPTIONS override_options() Index: gcc/config/m68k/m68k.c =================================================================== --- gcc/config/m68k/m68k.c 2007-01-09 15:01:45.000000000 +0000 +++ gcc/config/m68k/m68k.c 2007-01-09 15:01:45.000000000 +0000 @@ -2789,7 +2789,7 @@ standard_68881_constant_p (rtx x) /* fmovecr must be emulated on the 68040 and 68060, so it shouldn't be used at all on those chips. */ - if (TUNE_68040 || TUNE_68060) + if (TUNE_68040_60) return 0; if (! inited_68881_table) Index: gcc/config/m68k/m68k.md =================================================================== --- gcc/config/m68k/m68k.md 2007-01-09 15:01:45.000000000 +0000 +++ gcc/config/m68k/m68k.md 2007-01-09 15:01:45.000000000 +0000 @@ -618,10 +618,10 @@ (define_insn "movsi_const0" if (ADDRESS_REG_P (operands[0])) { /* On the '040, 'subl an,an' takes 2 clocks while lea takes only 1 */ - if (!TUNE_68040 && !TUNE_68060) - return "sub%.l %0,%0"; - else + if (TUNE_68040_60) return MOTOROLA ? "lea 0.w,%0" : "lea 0:w,%0"; + else + return "sub%.l %0,%0"; } /* moveq is faster on the 68000. */ if (DATA_REG_P (operands[0]) && TUNE_68000_10) @@ -846,10 +846,10 @@ (define_insn "" if (ADDRESS_REG_P (operands[0])) { /* On the '040, 'subl an,an' takes 2 clocks while lea takes only 1 */ - if (!TUNE_68040 && !TUNE_68060) - return "sub%.l %0,%0"; - else + if (TUNE_68040_60) return MOTOROLA ? "lea 0.w,%0" : "lea 0:w,%0"; + else + return "sub%.l %0,%0"; } /* moveq is faster on the 68000. */ if (DATA_REG_P (operands[0]) && TUNE_68000_10) @@ -2869,7 +2869,7 @@ (define_insn "muldf_68881" "TARGET_68881" { if (GET_CODE (operands[2]) == CONST_DOUBLE - && floating_exact_log2 (operands[2]) && !TUNE_68040 && !TUNE_68060) + && floating_exact_log2 (operands[2]) && !TUNE_68040_60) { int i = floating_exact_log2 (operands[2]); operands[2] = GEN_INT (i); ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 4/63] TARGET_COLDFIRE_FPU vs. TARGET_CFV4E 2007-01-10 10:34 ` [ColdFire 3/63] Add TUNE_68040_60 Richard Sandiford @ 2007-01-10 10:35 ` Richard Sandiford 2007-01-10 10:37 ` [ColdFire 5/63] Introduce TARGET_ISAB Richard Sandiford ` (2 more replies) 2007-01-10 17:48 ` [ColdFire 3/63] Add TUNE_68040_60 Jeffrey Law 1 sibling, 3 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 10:35 UTC (permalink / raw) To: gcc-patches Most of ColdFire FPU addressing code is conditional on TARGET_COLDFIRE_FPU, but two pieces are conditional on TARGET_CFV4E instead. Specifically: && (INTVAL (XEXP (X, 1)) == 2 \ || INTVAL (XEXP (X, 1)) == 4 \ || (INTVAL (XEXP (X, 1)) == 8 \ && (TARGET_CFV4E || !TARGET_COLDFIRE))))) and: if (ch && GET_CODE (XEXP (X, 1)) == REG \ && GET_CODE (XEXP (X, 0)) == REG) \ { if (TARGET_CFV4E && GET_MODE_CLASS (MODE) == MODE_FLOAT) \ { COPY_ONCE (X); X = force_operand (X, 0);} \ goto WIN; } \ TARGET_CFV4E is currently defined as TARGET_COLDFIRE_FPU, so there is no behavioural difference between the two. However, later patches in the series separate TARGET_COLDFIRE_FPU from TARGET_CFV4E, and I don't think the choice of macro is conceptually right in these two cases. For the first hunk: page 2-2 of the ColdFire Reference Manual makes it clear that a factor of 8 is only allowed if an FPU is present. It therefore seems logical to guard the first code with TARGET_COLDFIRE_FPU. For the second hunk: the ColdFire FPU does not allow indexed addressing modes, so as a practical measure, GO_IF_LEGITIMATE_ADDRESS stops any floating-point MEM from using indexes. This G_I_L_A code is already conditional on TARGET_COLDFIRE_FPU, and because the second hunk quoted above is part of the associated LEGITIMIZE_ADDRESS code, it too should use TARGET_COLDFIRE_FPU. Richard gcc/ 200x-xx-xx Julian Brown <julian@codesourcery.com> * config/m68k/m68k.h (LEGITIMATE_INDEX_P, LEGITIMIZE_ADDRESS): Use TARGET_COLDFIRE_FPU instead of TARGET_CFV4E. Index: gcc/config/m68k/m68k.h =================================================================== --- gcc/config/m68k/m68k.h 2007-01-09 15:01:45.000000000 +0000 +++ gcc/config/m68k/m68k.h 2007-01-09 15:01:46.000000000 +0000 @@ -771,7 +771,7 @@ #define LEGITIMATE_INDEX_P(X) \ && (INTVAL (XEXP (X, 1)) == 2 \ || INTVAL (XEXP (X, 1)) == 4 \ || (INTVAL (XEXP (X, 1)) == 8 \ - && (TARGET_CFV4E || !TARGET_COLDFIRE))))) + && (TARGET_COLDFIRE_FPU || !TARGET_COLDFIRE))))) /* Coldfire FPU only accepts addressing modes 2-5 */ #define GO_IF_COLDFIRE_FPU_LEGITIMATE_ADDRESS(MODE, X, ADDR) \ @@ -819,7 +819,8 @@ #define LEGITIMIZE_ADDRESS(X,OLDX,MODE,W { COPY_ONCE (X); XEXP (X, 1) = force_operand (XEXP (X, 1), 0);} \ if (ch && GET_CODE (XEXP (X, 1)) == REG \ && GET_CODE (XEXP (X, 0)) == REG) \ - { if (TARGET_CFV4E && GET_MODE_CLASS (MODE) == MODE_FLOAT) \ + { if (TARGET_COLDFIRE_FPU \ + && GET_MODE_CLASS (MODE) == MODE_FLOAT) \ { COPY_ONCE (X); X = force_operand (X, 0);} \ goto WIN; } \ if (ch) { GO_IF_LEGITIMATE_ADDRESS (MODE, X, WIN); } \ ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 5/63] Introduce TARGET_ISAB 2007-01-10 10:35 ` [ColdFire 4/63] TARGET_COLDFIRE_FPU vs. TARGET_CFV4E Richard Sandiford @ 2007-01-10 10:37 ` Richard Sandiford 2007-01-10 17:53 ` Jeffrey Law 2007-01-10 10:39 ` [ColdFire 6/63] Make gcc honour -m68010 Richard Sandiford 2007-01-10 17:52 ` [ColdFire 4/63] TARGET_COLDFIRE_FPU vs. TARGET_CFV4E Jeffrey Law 2 siblings, 1 reply; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 10:37 UTC (permalink / raw) To: gcc-patches The m68k backend uses TARGET_CFV4 as an ISA selector. However, the ColdFire ISA definition is not directly based on the version of the ColdFire core; it instead defines four separate ISA levels: ISA A, ISA A+, ISA B and ISA C. This series of patches tries to make gcc's ISA selection mirror the manual. The instructions selected by TARGET_CFV4 are ISA B instructions, so this patch adds a TARGET_ISAB and uses it instead of TARGET_CFV4. The patch defines TARGET_ISAB to TARGET_CFV4 for now, but this will change in later patches. Richard gcc/ 200x-xx-xx Julian Brown <julian@codesourcery.com> * config/m68k/m68k.h (TARGET_ISAB): New macro. * config/m68k/m68k.c: Use TARGET_ISAB rather than TARGET_CFV4. * config/m68k/m68k.md: Likewise. Index: gcc/config/m68k/m68k.h =================================================================== --- gcc/config/m68k/m68k.h 2007-01-09 15:01:46.000000000 +0000 +++ gcc/config/m68k/m68k.h 2007-01-09 15:01:47.000000000 +0000 @@ -126,6 +126,8 @@ #define TARGET_HARD_FLOAT (TARGET_68881 /* Size (in bytes) of FPU registers. */ #define TARGET_FP_REG_SIZE (TARGET_COLDFIRE ? 8 : 12) +#define TARGET_ISAB TARGET_CFV4 + #define TUNE_68000_10 (!TARGET_68020 && !TARGET_COLDFIRE) #define TUNE_68030 TARGET_68030 #define TUNE_68040 TARGET_68040 Index: gcc/config/m68k/m68k.c =================================================================== --- gcc/config/m68k/m68k.c 2007-01-09 15:01:45.000000000 +0000 +++ gcc/config/m68k/m68k.c 2007-01-09 15:01:47.000000000 +0000 @@ -1562,7 +1562,7 @@ const_method (rtx constant) if (USE_MOVQ ((u >> 16) | (u << 16))) return SWAP; - if (TARGET_CFV4) + if (TARGET_ISAB) { /* Try using MVZ/MVS with an immediate value to load constants. */ if (i >= 0 && i <= 65535) @@ -1779,7 +1779,7 @@ valid_mov3q_const (rtx constant) { int i; - if (TARGET_CFV4 && GET_CODE (constant) == CONST_INT) + if (TARGET_ISAB && GET_CODE (constant) == CONST_INT) { i = INTVAL (constant); if (i == -1 || (i >= 1 && i <= 7)) Index: gcc/config/m68k/m68k.md =================================================================== --- gcc/config/m68k/m68k.md 2007-01-09 15:01:45.000000000 +0000 +++ gcc/config/m68k/m68k.md 2007-01-09 15:01:47.000000000 +0000 @@ -682,13 +682,13 @@ (define_insn "" (define_insn "*movsi_cf" [(set (match_operand:SI 0 "nonimmediate_operand" "=r<Q>,g,U") (match_operand:SI 1 "general_operand" "g,r<Q>,U"))] - "TARGET_COLDFIRE && !TARGET_CFV4" + "TARGET_COLDFIRE && !TARGET_ISAB" "* return output_move_simode (operands);") (define_insn "*movsi_cfv4" [(set (match_operand:SI 0 "nonimmediate_operand" "=r<Q>,g,U") (match_operand:SI 1 "general_operand" "Rg,Rr<Q>,U"))] - "TARGET_CFV4" + "TARGET_ISAB" "* return output_move_simode (operands);") ;; Special case of fullword move, where we need to get a non-GOT PIC @@ -1389,7 +1389,7 @@ (define_insn_and_split "*zero_extendsidi (define_insn "*zero_extendhisi2_cf" [(set (match_operand:SI 0 "register_operand" "=d") (zero_extend:SI (match_operand:HI 1 "nonimmediate_src_operand" "rmS")))] - "TARGET_CFV4" + "TARGET_ISAB" "mvz%.w %1,%0") (define_insn "zero_extendhisi2" @@ -1413,7 +1413,7 @@ (define_insn "*zero_extendqihi2" (define_insn "*zero_extendqisi2_cfv4" [(set (match_operand:SI 0 "register_operand" "=d") (zero_extend:SI (match_operand:QI 1 "nonimmediate_src_operand" "dmS")))] - "TARGET_CFV4" + "TARGET_ISAB" "mvz%.b %1,%0") (define_insn "zero_extendqisi2" @@ -1427,7 +1427,9 @@ (define_insn "zero_extendqisi2" (define_split [(set (match_operand 0 "register_operand" "") (zero_extend (match_operand 1 "nonimmediate_src_operand" "")))] - "!TARGET_CFV4 && reload_completed && reg_mentioned_p (operands[0], operands[1])" + "!TARGET_ISAB + && reload_completed + && reg_mentioned_p (operands[0], operands[1])" [(set (strict_low_part (match_dup 2)) (match_dup 1)) (set (match_dup 0) @@ -1441,7 +1443,7 @@ (define_split (define_split [(set (match_operand 0 "register_operand" "") (zero_extend (match_operand 1 "nonimmediate_src_operand" "")))] - "!TARGET_CFV4 && reload_completed" + "!TARGET_ISAB && reload_completed" [(set (match_dup 0) (const_int 0)) (set (strict_low_part (match_dup 2)) @@ -1459,7 +1461,7 @@ (define_insn "extendqidi2" { CC_STATUS_INIT; operands[2] = gen_rtx_REG (SImode, REGNO (operands[0]) + 1); - if (TARGET_CFV4) + if (TARGET_ISAB) return "mvs%.b %1,%2\;smi %0\;extb%.l %0"; if (TARGET_68020 || TARGET_COLDFIRE) { @@ -1485,7 +1487,7 @@ (define_insn "extendhidi2" { CC_STATUS_INIT; operands[2] = gen_rtx_REG (SImode, REGNO (operands[0]) + 1); - if (TARGET_CFV4) + if (TARGET_ISAB) return "mvs%.w %1,%2\;smi %0\;extb%.l %0"; if (TARGET_68020 || TARGET_COLDFIRE) return "move%.w %1,%2\;ext%.l %2\;smi %0\;extb%.l %0"; @@ -1549,14 +1551,14 @@ (define_insn "*cfv4_extendhisi2" [(set (match_operand:SI 0 "nonimmediate_operand" "=d") (sign_extend:SI (match_operand:HI 1 "nonimmediate_src_operand" "rmS")))] - "TARGET_CFV4" + "TARGET_ISAB" "mvs%.w %1,%0") (define_insn "*68k_extendhisi2" [(set (match_operand:SI 0 "nonimmediate_operand" "=*d,a") (sign_extend:SI (match_operand:HI 1 "nonimmediate_src_operand" "0,rmS")))] - "!TARGET_CFV4" + "!TARGET_ISAB" { if (ADDRESS_REG_P (operands[0])) return "move%.w %1,%0"; @@ -1578,13 +1580,13 @@ (define_expand "extendqisi2" (define_insn "*cfv4_extendqisi2" [(set (match_operand:SI 0 "nonimmediate_operand" "=d") (sign_extend:SI (match_operand:QI 1 "nonimmediate_operand" "rms")))] - "TARGET_CFV4" + "TARGET_ISAB" "mvs%.b %1,%0") (define_insn "*68k_extendqisi2" [(set (match_operand:SI 0 "nonimmediate_operand" "=d") (sign_extend:SI (match_operand:QI 1 "nonimmediate_operand" "0")))] - "TARGET_68020 || (TARGET_COLDFIRE && !TARGET_CFV4)" + "TARGET_68020 || (TARGET_COLDFIRE && !TARGET_ISAB)" "extb%.l %0") \f ;; Conversions between float and double. @@ -3094,7 +3096,7 @@ (define_insn "udivmodhi4" (umod:HI (match_dup 1) (match_dup 2)))] "!TARGET_COLDFIRE || TARGET_CF_HWDIV" { - if (TARGET_CFV4) + if (TARGET_ISAB) output_asm_insn (MOTOROLA ? "mvz%.w %0,%0\;divu%.w %2,%0" : "mvz%.w %0,%0\;divu %2,%0", @@ -3218,7 +3220,8 @@ (define_insn "andsi3_5200" (match_operand:SI 2 "general_src_operand" "d,dmsK")))] "TARGET_COLDFIRE" { - if (TARGET_CFV4 && DATA_REG_P (operands[0]) + if (TARGET_ISAB + && DATA_REG_P (operands[0]) && GET_CODE (operands[2]) == CONST_INT) { if (INTVAL (operands[2]) == 0x000000ff) ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 5/63] Introduce TARGET_ISAB 2007-01-10 10:37 ` [ColdFire 5/63] Introduce TARGET_ISAB Richard Sandiford @ 2007-01-10 17:53 ` Jeffrey Law 0 siblings, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-01-10 17:53 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches On Wed, 2007-01-10 at 10:37 +0000, Richard Sandiford wrote: > The m68k backend uses TARGET_CFV4 as an ISA selector. However, the ColdFire > ISA definition is not directly based on the version of the ColdFire core; > it instead defines four separate ISA levels: ISA A, ISA A+, ISA B and > ISA C. This series of patches tries to make gcc's ISA selection mirror > the manual. > > The instructions selected by TARGET_CFV4 are ISA B instructions, > so this patch adds a TARGET_ISAB and uses it instead of TARGET_CFV4. > The patch defines TARGET_ISAB to TARGET_CFV4 for now, but this will > change in later patches. > > Richard > > > gcc/ > 200x-xx-xx Julian Brown <julian@codesourcery.com> > > * config/m68k/m68k.h (TARGET_ISAB): New macro. > * config/m68k/m68k.c: Use TARGET_ISAB rather than TARGET_CFV4. > * config/m68k/m68k.md: Likewise. OK. Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 6/63] Make gcc honour -m68010 2007-01-10 10:35 ` [ColdFire 4/63] TARGET_COLDFIRE_FPU vs. TARGET_CFV4E Richard Sandiford 2007-01-10 10:37 ` [ColdFire 5/63] Introduce TARGET_ISAB Richard Sandiford @ 2007-01-10 10:39 ` Richard Sandiford 2007-01-10 10:45 ` [ColdFire 7/63] Default target selection and --with-cpu support Richard Sandiford 2007-01-10 18:07 ` [ColdFire 6/63] Make gcc honour -m68010 Jeffrey Law 2007-01-10 17:52 ` [ColdFire 4/63] TARGET_COLDFIRE_FPU vs. TARGET_CFV4E Jeffrey Law 2 siblings, 2 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 10:39 UTC (permalink / raw) To: gcc-patches gcc already recognises a -m68010 option, but it only passes the option down to the assembler; it does nothing with the option itself. Comments show that someone did want gcc to distinguish between the 68000 and 68010, but for some reason they never added the code. This patch fixes that. It's a step towards rationalising the architecture selection code, and it is needed so that later patches in the series do not regress on 680x0 support. Also, adding this option means we can simplify the netbsd configuration a little, as the macros defined by its CPP spec are now handled by TARGET_CPU_CPP_BUILTINS. Note that the MASK_* stuff is only temporary. A later patch moves to a (hopefully!) saner system. Richard gcc/ * config.gcc (m68010-*-netbsdelf*): Add MASK_68010. (m68k*-*-netbsdelf*, m68k*-*-openbsd*, m68k*-linux*): Add MASK_68010 alongside MASK_68020. * doc/invoke.texi: Document -m68010. * config/m68k/m68k.opt (m68010): New. * config/m68k/m68k.h (TARGET_CPU_CPP_BUILTINS): Define mc68010 if TUNE_68010. (TUNE_68010): New macro. * config/m68k/m68k-none.h (M68K_CPU_m68k, M68K_CPU_m68010) (M68K_CPU_m68020, M68K_CPU_m68030, M68K_CPU_m68040) (M68K_CPU_m68332): Add MASK_68010. * config/m68k/linux.h (TARGET_DEFAULT): Add MASK_68010 to fallback definition. * config/m68k/netbsd-elf.h (CPP_CPU_SPEC): Remove now-redundant defines. * config/m68k/m68k.c (MASK_ALL_CPU_BITS): Add MASK_68010. (m68k_handle_option): Handle OPT_m68010. Add MASK_68010 to all entries that use MASK_68020. (output_move_simode_const, output_move_himode, output_move_qimode) (output_move_stricthi, output_move_strictqi): Use TARGET_68010 instead of TARGET_68020 to select clr behavior. Remove comment about there being no TARGET_68010. * config/m68k/m68k.md: Likewise throughout. Index: gcc/config.gcc =================================================================== --- gcc/config.gcc 2007-01-09 15:01:42.000000000 +0000 +++ gcc/config.gcc 2007-01-09 15:01:47.000000000 +0000 @@ -1491,16 +1491,16 @@ m68010-*-netbsdelf* | m68k*-*-netbsdelf* tm_defines="${tm_defines} MOTOROLA USE_GAS" case ${target} in m68010*) - target_cpu_default="0" + target_cpu_default="MASK_68010" ;; *) - target_cpu_default="MASK_68020|MASK_68881|MASK_BITFIELD" + target_cpu_default="MASK_68020|MASK_68010|MASK_68881|MASK_BITFIELD" ;; esac ;; m68k*-*-openbsd*) # needed to unconfuse gdb - tm_defines="${tm_defines} OBSD_OLD_GAS TARGET_DEFAULT=(MASK_68020|MASK_68881|MASK_BITFIELD)" + tm_defines="${tm_defines} OBSD_OLD_GAS TARGET_DEFAULT=(MASK_68020|MASK_68010|MASK_68881|MASK_BITFIELD)" tm_file="m68k/m68k.h openbsd.h m68k/openbsd.h" tmake_file="t-libc-ok t-openbsd m68k/t-openbsd" # we need collect2 until our bug is fixed... @@ -3030,25 +3030,25 @@ case ${target} in case "x$with_cpu" in x) # The most generic - target_cpu_default2="(MASK_68020|MASK_68881|MASK_BITFIELD)" + target_cpu_default2="(MASK_68020|MASK_68010|MASK_68881|MASK_BITFIELD)" ;; xm68020) - target_cpu_default2="(MASK_68020|MASK_68881|MASK_BITFIELD)" + target_cpu_default2="(MASK_68020|MASK_68010|MASK_68881|MASK_BITFIELD)" ;; xm68030) - target_cpu_default2="(MASK_68030|MASK_68020|MASK_68881|MASK_BITFIELD)" + target_cpu_default2="(MASK_68030|MASK_68020|MASK_68010|MASK_68881|MASK_BITFIELD)" ;; xm68040) - target_cpu_default2="(MASK_68040|MASK_68040_ONLY|MASK_68020|MASK_68881|MASK_BITFIELD)" + target_cpu_default2="(MASK_68040|MASK_68040_ONLY|MASK_68020|MASK_68010|MASK_68881|MASK_BITFIELD)" ;; xm68060) - target_cpu_default2="(MASK_68060|MASK_68040_ONLY|MASK_68020|MASK_68881|MASK_BITFIELD)" + target_cpu_default2="(MASK_68060|MASK_68040_ONLY|MASK_68020|MASK_68010|MASK_68881|MASK_BITFIELD)" ;; xm68020-40) - target_cpu_default2="(MASK_BITFIELD|MASK_68881|MASK_68020|MASK_68040)" + target_cpu_default2="(MASK_BITFIELD|MASK_68881|MASK_68020|MASK_68010|MASK_68040)" ;; xm68020-60) - target_cpu_default2="(MASK_BITFIELD|MASK_68881|MASK_68020|MASK_68040|MASK_68060)" + target_cpu_default2="(MASK_BITFIELD|MASK_68881|MASK_68020|MASK_68010|MASK_68040|MASK_68060)" ;; *) echo "Unknown CPU used in --with-cpu=$with_cpu" 1>&2 Index: gcc/doc/invoke.texi =================================================================== --- gcc/doc/invoke.texi 2007-01-09 15:01:42.000000000 +0000 +++ gcc/doc/invoke.texi 2007-01-09 15:01:47.000000000 +0000 @@ -10238,6 +10238,11 @@ when the compiler is configured for 6800 Use this option for microcontrollers with a 68000 or EC000 core, including the 68008, 68302, 68306, 68307, 68322, 68328 and 68356. +@item -m68010 +@opindex m68010 +Generate output for a 68010. This is the default +when the compiler is configured for 68010-based systems. + @item -m68020 @itemx -mc68020 @opindex m68020 Index: gcc/config/m68k/m68k.opt =================================================================== --- gcc/config/m68k/m68k.opt 2007-01-09 15:01:43.000000000 +0000 +++ gcc/config/m68k/m68k.opt 2007-01-09 15:01:47.000000000 +0000 @@ -47,6 +47,10 @@ m68000 Target RejectNegative Generate code for a 68000 +m68010 +Target RejectNegative Mask(68010) +Generate code for a 68010 + m68020 Target RejectNegative Mask(68020) Generate code for a 68020 Index: gcc/config/m68k/m68k.h =================================================================== --- gcc/config/m68k/m68k.h 2007-01-09 15:01:47.000000000 +0000 +++ gcc/config/m68k/m68k.h 2007-01-09 15:01:47.000000000 +0000 @@ -64,6 +64,8 @@ #define TARGET_CPU_CPP_BUILTINS() \ builtin_define_std ("mc68030"); \ else if (TARGET_68020) \ builtin_define_std ("mc68020"); \ + else if (TUNE_68010) \ + builtin_define_std ("mc68010"); \ if (TARGET_68881) \ builtin_define ("__HAVE_68881__"); \ if (TUNE_CPU32) \ @@ -129,6 +131,7 @@ #define TARGET_FP_REG_SIZE (TARGET_COLDF #define TARGET_ISAB TARGET_CFV4 #define TUNE_68000_10 (!TARGET_68020 && !TARGET_COLDFIRE) +#define TUNE_68010 TARGET_68010 #define TUNE_68030 TARGET_68030 #define TUNE_68040 TARGET_68040 #define TUNE_68060 TARGET_68060 Index: gcc/config/m68k/m68k-none.h =================================================================== --- gcc/config/m68k/m68k-none.h 2007-01-09 15:01:43.000000000 +0000 +++ gcc/config/m68k/m68k-none.h 2007-01-09 15:01:47.000000000 +0000 @@ -25,14 +25,14 @@ #define TARGET_CPU_DEFAULT M68K_CPU_m68k /* These are values set by the configure script in TARGET_CPU_DEFAULT. They are (sequential integer + (desired value for TARGET_DEFAULT) << 4). */ -#define M68K_CPU_m68k (0 + ((MASK_68020|MASK_68881|MASK_BITFIELD)<<4)) +#define M68K_CPU_m68k (0 + ((MASK_68020|MASK_68010|MASK_68881|MASK_BITFIELD)<<4)) #define M68K_CPU_m68000 (1 + (0 << 4)) -#define M68K_CPU_m68010 (1 + (0 << 4)) /* make same as m68000 */ -#define M68K_CPU_m68020 (2 + ((MASK_68020|MASK_68881|MASK_BITFIELD) << 4)) -#define M68K_CPU_m68030 (3 + ((MASK_68030|MASK_68020|MASK_68881|MASK_BITFIELD) << 4)) -#define M68K_CPU_m68040 (4 + ((MASK_68040_ONLY|MASK_68020|MASK_68881|MASK_BITFIELD) << 4)) +#define M68K_CPU_m68010 (1 + (MASK_68010 << 4)) +#define M68K_CPU_m68020 (2 + ((MASK_68020|MASK_68010|MASK_68881|MASK_BITFIELD) << 4)) +#define M68K_CPU_m68030 (3 + ((MASK_68030|MASK_68020|MASK_68010|MASK_68881|MASK_BITFIELD) << 4)) +#define M68K_CPU_m68040 (4 + ((MASK_68040_ONLY|MASK_68020|MASK_68010|MASK_68881|MASK_BITFIELD) << 4)) #define M68K_CPU_m68302 (5 + (0 << 4)) -#define M68K_CPU_m68332 (6 + (MASK_68020 << 4)) +#define M68K_CPU_m68332 (6 + ((MASK_68020|MASK_68010) << 4)) /* This is tested for below, so if target wants to override this, it just set this first in cover file. */ Index: gcc/config/m68k/linux.h =================================================================== --- gcc/config/m68k/linux.h 2007-01-09 15:01:43.000000000 +0000 +++ gcc/config/m68k/linux.h 2007-01-09 15:01:47.000000000 +0000 @@ -29,7 +29,7 @@ #define TARGET_VERSION fprintf (stderr, #ifdef TARGET_CPU_DEFAULT #define TARGET_DEFAULT TARGET_CPU_DEFAULT #else -#define TARGET_DEFAULT (MASK_BITFIELD|MASK_68881|MASK_68020) +#define TARGET_DEFAULT (MASK_BITFIELD|MASK_68881|MASK_68010|MASK_68020) #endif /* for 68k machines this only needs to be TRUE for the 68000 */ Index: gcc/config/m68k/netbsd-elf.h =================================================================== --- gcc/config/m68k/netbsd-elf.h 2007-01-09 15:01:45.000000000 +0000 +++ gcc/config/m68k/netbsd-elf.h 2007-01-09 15:01:47.000000000 +0000 @@ -59,11 +59,7 @@ #define EXTRA_SPECS \ #define CPP_CPU_SPEC \ - "%{m68010:-D__mc68010__} \ - %{m68020:-D__mc68020__} \ - %{m68030:-D__mc68030__} \ - %{m68040:-D__mc68040__} \ - %(cpp_cpu_default_spec)" + "%(cpp_cpu_default_spec)" #undef TARGET_VERSION Index: gcc/config/m68k/m68k.c =================================================================== --- gcc/config/m68k/m68k.c 2007-01-09 15:01:47.000000000 +0000 +++ gcc/config/m68k/m68k.c 2007-01-09 15:01:47.000000000 +0000 @@ -206,7 +206,7 @@ struct gcc_target targetm = TARGET_INITI #define MASK_ALL_CPU_BITS \ (MASK_COLDFIRE | MASK_CF_HWDIV | MASK_68060 | MASK_68040 \ - | MASK_68040_ONLY | MASK_68030 | MASK_68020 | MASK_BITFIELD) + | MASK_68040_ONLY | MASK_68030 | MASK_68020 | MASK_68010 | MASK_BITFIELD) /* Implement TARGET_HANDLE_OPTION. */ @@ -250,37 +250,43 @@ m68k_handle_option (size_t code, const c target_flags &= ~(MASK_ALL_CPU_BITS | MASK_68881); return true; + case OPT_m68010: + target_flags &= ~(MASK_ALL_CPU_BITS | MASK_68881); + target_flags |= MASK_68010; + return true; + case OPT_m68020: case OPT_mc68020: target_flags &= ~MASK_ALL_CPU_BITS; - target_flags |= MASK_68020 | MASK_BITFIELD; + target_flags |= MASK_68010 | MASK_68020 | MASK_BITFIELD; return true; case OPT_m68020_40: target_flags &= ~MASK_ALL_CPU_BITS; - target_flags |= MASK_BITFIELD | MASK_68881 | MASK_68020 | MASK_68040; + target_flags |= (MASK_BITFIELD | MASK_68881 | MASK_68010 + | MASK_68020 | MASK_68040); return true; case OPT_m68020_60: target_flags &= ~MASK_ALL_CPU_BITS; - target_flags |= (MASK_BITFIELD | MASK_68881 | MASK_68020 - | MASK_68040 | MASK_68060); + target_flags |= (MASK_BITFIELD | MASK_68881 | MASK_68010 + | MASK_68020 | MASK_68040 | MASK_68060); return true; case OPT_m68030: target_flags &= ~MASK_ALL_CPU_BITS; - target_flags |= MASK_68020 | MASK_68030 | MASK_BITFIELD; + target_flags |= MASK_68010 | MASK_68020 | MASK_68030 | MASK_BITFIELD; return true; case OPT_m68040: target_flags &= ~MASK_ALL_CPU_BITS; - target_flags |= (MASK_68020 | MASK_68881 | MASK_BITFIELD + target_flags |= (MASK_68010 | MASK_68020 | MASK_68881 | MASK_BITFIELD | MASK_68040_ONLY | MASK_68040); return true; case OPT_m68060: target_flags &= ~MASK_ALL_CPU_BITS; - target_flags |= (MASK_68020 | MASK_68881 | MASK_BITFIELD + target_flags |= (MASK_68010 | MASK_68020 | MASK_68881 | MASK_BITFIELD | MASK_68040_ONLY | MASK_68060); return true; @@ -291,7 +297,7 @@ m68k_handle_option (size_t code, const c case OPT_m68332: case OPT_mcpu32: target_flags &= ~(MASK_ALL_CPU_BITS | MASK_68881); - target_flags |= MASK_68020; + target_flags |= MASK_68010 | MASK_68020; return true; case OPT_mshared_library_id_: @@ -1795,9 +1801,8 @@ output_move_simode_const (rtx *operands) if (operands[1] == const0_rtx && (DATA_REG_P (operands[0]) || GET_CODE (operands[0]) == MEM) - /* clr insns on 68000 read before writing. - This isn't so on the 68010, but we have no TARGET_68010. */ - && ((TARGET_68020 || TARGET_COLDFIRE) + /* clr insns on 68000 read before writing. */ + && ((TARGET_68010 || TARGET_COLDFIRE) || !(GET_CODE (operands[0]) == MEM && MEM_VOLATILE_P (operands[0])))) return "clr%.l %0"; @@ -1854,9 +1859,8 @@ output_move_himode (rtx *operands) if (operands[1] == const0_rtx && (DATA_REG_P (operands[0]) || GET_CODE (operands[0]) == MEM) - /* clr insns on 68000 read before writing. - This isn't so on the 68010, but we have no TARGET_68010. */ - && ((TARGET_68020 || TARGET_COLDFIRE) + /* clr insns on 68000 read before writing. */ + && ((TARGET_68010 || TARGET_COLDFIRE) || !(GET_CODE (operands[0]) == MEM && MEM_VOLATILE_P (operands[0])))) return "clr%.w %0"; @@ -1908,10 +1912,9 @@ output_move_qimode (rtx *operands) && ! ADDRESS_REG_P (operands[1]) && ! TARGET_COLDFIRE)); - /* clr and st insns on 68000 read before writing. - This isn't so on the 68010, but we have no TARGET_68010. */ + /* clr and st insns on 68000 read before writing. */ if (!ADDRESS_REG_P (operands[0]) - && ((TARGET_68020 || TARGET_COLDFIRE) + && ((TARGET_68010 || TARGET_COLDFIRE) || !(GET_CODE (operands[0]) == MEM && MEM_VOLATILE_P (operands[0])))) { if (operands[1] == const0_rtx) @@ -1944,9 +1947,8 @@ output_move_qimode (rtx *operands) output_move_stricthi (rtx *operands) { if (operands[1] == const0_rtx - /* clr insns on 68000 read before writing. - This isn't so on the 68010, but we have no TARGET_68010. */ - && ((TARGET_68020 || TARGET_COLDFIRE) + /* clr insns on 68000 read before writing. */ + && ((TARGET_68010 || TARGET_COLDFIRE) || !(GET_CODE (operands[0]) == MEM && MEM_VOLATILE_P (operands[0])))) return "clr%.w %0"; return "move%.w %1,%0"; @@ -1956,9 +1958,8 @@ output_move_stricthi (rtx *operands) output_move_strictqi (rtx *operands) { if (operands[1] == const0_rtx - /* clr insns on 68000 read before writing. - This isn't so on the 68010, but we have no TARGET_68010. */ - && ((TARGET_68020 || TARGET_COLDFIRE) + /* clr insns on 68000 read before writing. */ + && ((TARGET_68010 || TARGET_COLDFIRE) || !(GET_CODE (operands[0]) == MEM && MEM_VOLATILE_P (operands[0])))) return "clr%.b %0"; return "move%.b %1,%0"; Index: gcc/config/m68k/m68k.md =================================================================== --- gcc/config/m68k/m68k.md 2007-01-09 15:01:47.000000000 +0000 +++ gcc/config/m68k/m68k.md 2007-01-09 15:01:47.000000000 +0000 @@ -611,8 +611,7 @@ (define_insn "movsi_const0" [(set (match_operand:SI 0 "nonimmediate_operand" "=g") (const_int 0))] ;; clr insns on 68000 read before writing. - ;; This isn't so on the 68010, but we have no TARGET_68010. - "((TARGET_68020 || TARGET_COLDFIRE) + "((TARGET_68010 || TARGET_COLDFIRE) || !(GET_CODE (operands[0]) == MEM && MEM_VOLATILE_P (operands[0])))" { if (ADDRESS_REG_P (operands[0])) @@ -838,9 +837,8 @@ (define_insn "" return "fmove%.s %f1,%0"; } if (operands[1] == CONST0_RTX (SFmode) - /* clr insns on 68000 read before writing. - This isn't so on the 68010, but we have no TARGET_68010. */ - && ((TARGET_68020 || TARGET_COLDFIRE) + /* clr insns on 68000 read before writing. */ + && ((TARGET_68010 || TARGET_COLDFIRE) || !(GET_CODE (operands[0]) == MEM && MEM_VOLATILE_P (operands[0])))) { if (ADDRESS_REG_P (operands[0])) @@ -6731,9 +6729,8 @@ (define_peephole if (operands[1] == const0_rtx && (DATA_REG_P (operands[0]) || GET_CODE (operands[0]) == MEM) - /* clr insns on 68000 read before writing. - This isn't so on the 68010, but we have no TARGET_68010. */ - && ((TARGET_68020 || TARGET_COLDFIRE) + /* clr insns on 68000 read before writing. */ + && ((TARGET_68010 || TARGET_COLDFIRE) || !(GET_CODE (operands[0]) == MEM && MEM_VOLATILE_P (operands[0])))) return "clr%.w %0"; ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 7/63] Default target selection and --with-cpu support 2007-01-10 10:39 ` [ColdFire 6/63] Make gcc honour -m68010 Richard Sandiford @ 2007-01-10 10:45 ` Richard Sandiford 2007-01-10 10:46 ` [ColdFire 8/63] Share ASM_SPEC code between targets Richard Sandiford 2007-01-10 18:09 ` [ColdFire 7/63] Default target selection and --with-cpu support Jeffrey Law 2007-01-10 18:07 ` [ColdFire 6/63] Make gcc honour -m68010 Jeffrey Law 1 sibling, 2 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 10:45 UTC (permalink / raw) To: gcc-patches The m68k port allows the default target to be specified at configure time. However, the code that does this predates OPTION_DEFAULT_SPECS and uses a hairy system of default masks instead. This patch: (1) extends the existing GNU/Linux --with-cpu code to all m68k targets. (2) allows --with-cpu=m68000 and --with-cpu=m68010 too. (3) makes each m68k-* configuration set the default target using default_m68k_cpu. Currently all m68k-* targets use a default of 68020, but the associated ColdFire configurations do not use the same defaults as each other, so it seemed like a good idea to be consistent. (4) makes m680[012]0-* configurations use the first part of the triplet as the default target. (5) uses OPTIONS_DEFAULT_SPECS to make sure that a CPU option is always present on the command line, and cleans up config/m68k accordingly. Note that unlike other targets, the value of with_cpu is a command-line option without the leading "-"; this is to support both the traditional -m<cpu> and upcoming -mcpu=<cpu> options. (6) makes MASK_68881 the default. This is not a behavioural change: if --with-cpu=m68020 is given or implied, the default will be hard float, while if any other --with-cpu=mfoo is given, the mask will be set or cleared when the -mfoo option is processed. One disadvantage of this patch in isolation is that you must remember to pass the CPU option when invoking cc1 directly. A later patch fixes that, so that cc1's default is the same as the driver's. Richard gcc/ 200x-xx-xx Nathan Sidwell <nathan@codesourcery.com> Richard Sandiford <richard@codesourcery.com> Julian Brown <julian@codesourcery.com> * config.gcc (m68k-*-aout*, m68k-*-coff*, m68020-*-elf*, m68k-*-elf*) (m68k-*-uclinux*, m68k-*-linux*, m68k-*-rtems*): Set default_m68k_cpu to the configuration's default CPU. (m68010-*-netbsdelf*, m68k*-*-netbsdelf*, m68k*-*-openbsd*): Likewise. Remove default masks. (m680[012]0-*-*): Set the default with_cpu to the first part of the target name. (m68k*-*-*): Set the default with_cpu to m$default_m68k_cpu. (m68k*-*-linux): Extend the --with-cpu handling to... (m680[012]0-*-*, m68k*-*-*): ...these configurations. Allow m68000 and m68010. Don't set target_cpu_default2. * doc/install.texi: Document --with-cpu for m68k. * config/m68k/m68k.h (OPTION_DEFAULT_SPECS): Define. * config/m68k/m68k-none.h (TARGET_CPU_DEFAULT, M68K_CPU_m68k) (M68K_CPU_m68000, M68K_CPU_m68010, M68K_CPU_m68020, M68K_CPU_m68030) (M68K_CPU_m68040, M68K_CPU_m68302, M68K_CPU_m68332, TARGET_DEFAULT) (ASM_CPU_DEFAULT_SPEC, CC1_CPU_DEFAULT_SPEC): Delete. (ASM_SPEC): Remove use of %(asm_cpu_default). (EXTRA_SPECS, SUBTARGET_EXTRA_SPECS, MULTILIB_DEFAULTS): Delete. * config/m68k/linux.h (TARGET_DEFAULT): Delete. (CPP_SPEC): Merge definitions. Do not handle __HAVE_68881__ here. * config/m68k/netbsd-elf.h (TARGET_OS_CPP_BUILTINS): Define __HAVE_FPU__ if TARGET_HARD_FLOAT. (TARGET_DEFAULT): Delete. (EXTRA_SPECS): Delete cpp_cpu_default_spec, cpp_cpu_spec, cpp_fpu_spec, asm_default_spec and netbsd_cpp_spec. (CPP_CPU_SPEC): Delete. (TARGET_VERSION): Merge definitions, using TARGET_68010 to pick the appropriate string. (CPP_CPU_DEFAULT_SPEC, ASM_DEFAULT_SPEC, CPP_FPU_SPEC): Delete. (CPP_SPEC): Define to NETBSD_CPP_SPEC. (ASM_SPEC): Don't use %(asm_default_spec). * config/m68k/m68k.c (TARGET_DEFAULT_TARGET_FLAGS): Remove TARGET_DEFAULT and add MASK_68881. * config/m68k/m68k.md: Remove mention of TARGET_DEFAULT from comments. Index: gcc/config.gcc =================================================================== --- gcc/config.gcc 2007-01-09 15:01:47.000000000 +0000 +++ gcc/config.gcc 2007-01-09 15:01:49.000000000 +0000 @@ -1471,42 +1471,40 @@ m68hc12-*-*|m6812-*-*) use_fixproto=yes ;; m68k-*-aout*) + default_m68k_cpu=68020 tmake_file=m68k/t-m68kbare tm_file="m68k/m68k.h m68k/m68k-none.h m68k/m68kemb.h m68k/m68k-aout.h libgloss.h" ;; m68k-*-coff*) + default_m68k_cpu=68020 tmake_file=m68k/t-m68kbare tm_defines="${tm_defines} MOTOROLA USE_GAS" tm_file="m68k/m68k.h m68k/m68k-none.h m68k/m68kemb.h dbxcoff.h m68k/coff.h dbx.h" use_fixproto=yes ;; m68020-*-elf* | m68k-*-elf*) + default_m68k_cpu=68020 tm_file="m68k/m68k.h m68k/m68k-none.h m68k/m68kelf.h dbxelf.h elfos.h m68k/m68kemb.h m68k/m68020-elf.h" tm_defines="${tm_defines} MOTOROLA USE_GAS" tmake_file=m68k/t-m68kelf extra_parts="crtbegin.o crtend.o" ;; m68010-*-netbsdelf* | m68k*-*-netbsdelf*) + default_m68k_cpu=68020 tm_file="${tm_file} dbxelf.h elfos.h netbsd.h netbsd-elf.h m68k/netbsd-elf.h" tm_defines="${tm_defines} MOTOROLA USE_GAS" - case ${target} in - m68010*) - target_cpu_default="MASK_68010" - ;; - *) - target_cpu_default="MASK_68020|MASK_68010|MASK_68881|MASK_BITFIELD" - ;; - esac ;; m68k*-*-openbsd*) + default_m68k_cpu=68020 # needed to unconfuse gdb - tm_defines="${tm_defines} OBSD_OLD_GAS TARGET_DEFAULT=(MASK_68020|MASK_68010|MASK_68881|MASK_BITFIELD)" + tm_defines="${tm_defines} OBSD_OLD_GAS" tm_file="m68k/m68k.h openbsd.h m68k/openbsd.h" tmake_file="t-libc-ok t-openbsd m68k/t-openbsd" # we need collect2 until our bug is fixed... use_collect2=yes ;; m68k-*-uclinux*) # Motorola m68k/ColdFire running uClinux with uClibc + default_m68k_cpu=68020 tm_file="m68k/m68k.h m68k/m68k-none.h m68k/m68kelf.h dbxelf.h elfos.h m68k/uclinux.h" tm_defines="${tm_defines} MOTOROLA USE_GAS" tmake_file=m68k/t-uclinux @@ -1515,6 +1513,7 @@ m68k-*-uclinux*) # Motorola m68k/ColdFi m68k-*-linux*) # Motorola m68k's running GNU/Linux # with ELF format using glibc 2 # aka the GNU/Linux C library 6. + default_m68k_cpu=68020 tm_file="m68k/m68k.h dbxelf.h elfos.h svr4.h linux.h m68k/linux.h" extra_options="${extra_options} m68k/ieee.opt" tm_defines="${tm_defines} MOTOROLA USE_GAS" @@ -1525,6 +1524,7 @@ m68k-*-linux*) # Motorola m68k's runnin fi ;; m68k-*-rtems*) + default_m68k_cpu=68020 tmake_file="m68k/t-m68kbare m68k/t-crtstuff t-rtems m68k/t-rtems" tm_file="m68k/m68k.h m68k/m68k-none.h m68k/m68kelf.h dbxelf.h elfos.h m68k/m68kemb.h m68k/m68020-elf.h m68k/rtemself.h rtems.h" tm_defines="${tm_defines} MOTOROLA USE_GAS" @@ -2618,6 +2618,12 @@ if test x$with_cpu = x ; then frv550-*-*linux*) with_cpu=fr550 ;; + m680[012]0-*-*) + with_cpu=`echo ${target} | sed 's/-.*$//'` + ;; + m68k*-*-*) + with_cpu=m${default_m68k_cpu} + ;; sparc*-*-*) with_cpu="`echo ${target} | sed 's/-.*$//'`" ;; @@ -2766,15 +2772,17 @@ case "${target}" in esac ;; - m68k*-linux*) + m680[012]0-*-* | m68k*-*-*) supported_defaults="cpu" + + # We always have a $with_cpu setting here. case "$with_cpu" in - "" | "m68020" | "m68030" | "m68040" | "m68060" | "m68020-40" | "m68020-60") + "m68000" | "m68010" | "m68020" | "m68030" | "m68040" | "m68060" | "m68020-40" | "m68020-60") # OK ;; *) echo "Unknown CPU used in --with-cpu=$with_cpu, known values:" 1>&2 - echo "m68020 m68030 m68040 m68060 m68020-40 m68020-60" 1>&2 + echo "m68000 m68010 m68020 m68030 m68040 m68060 m68020-40 m68020-60" 1>&2 exit 1 ;; esac @@ -3026,37 +3034,6 @@ case ${target} in fi ;; - m68k*-linux*) - case "x$with_cpu" in - x) - # The most generic - target_cpu_default2="(MASK_68020|MASK_68010|MASK_68881|MASK_BITFIELD)" - ;; - xm68020) - target_cpu_default2="(MASK_68020|MASK_68010|MASK_68881|MASK_BITFIELD)" - ;; - xm68030) - target_cpu_default2="(MASK_68030|MASK_68020|MASK_68010|MASK_68881|MASK_BITFIELD)" - ;; - xm68040) - target_cpu_default2="(MASK_68040|MASK_68040_ONLY|MASK_68020|MASK_68010|MASK_68881|MASK_BITFIELD)" - ;; - xm68060) - target_cpu_default2="(MASK_68060|MASK_68040_ONLY|MASK_68020|MASK_68010|MASK_68881|MASK_BITFIELD)" - ;; - xm68020-40) - target_cpu_default2="(MASK_BITFIELD|MASK_68881|MASK_68020|MASK_68010|MASK_68040)" - ;; - xm68020-60) - target_cpu_default2="(MASK_BITFIELD|MASK_68881|MASK_68020|MASK_68010|MASK_68040|MASK_68060)" - ;; - *) - echo "Unknown CPU used in --with-cpu=$with_cpu" 1>&2 - exit 1 - ;; - esac - ;; - hppa*-*-* | parisc*-*-*) target_cpu_default2="MASK_BIG_SWITCH" if test x$gas = xyes Index: gcc/doc/install.texi =================================================================== --- gcc/doc/install.texi 2007-01-09 15:01:42.000000000 +0000 +++ gcc/doc/install.texi 2007-01-09 15:01:49.000000000 +0000 @@ -994,8 +994,8 @@ This is an alias for @option{--enable-tl @item --with-cpu=@var{cpu} Specify which cpu variant the compiler should generate code for by default. @var{cpu} will be used as the default value of the @option{-mcpu=} switch. -This option is only supported on some targets, including ARM, i386, PowerPC, -and SPARC@. +This option is only supported on some targets, including ARM, i386, M68k, +PowerPC, and SPARC@. @item --with-schedule=@var{cpu} @itemx --with-arch=@var{cpu} @@ -3386,6 +3386,12 @@ applications. There are no standard Uni @html <hr /> @end html +@heading @anchor{m68k-*-*}m68k-*-* +You can specify a default target using @option{--with-cpu=@var{target}}. +The recognized values for @var{target} are: @samp{m68000}, @samp{m68010}, +@samp{m68020}, @samp{m68030}, @samp{m68040}, @samp{m68060}, @samp{m68020-40} +and @samp{m68020-60}. + @heading @anchor{m68k-hp-hpux}m68k-hp-hpux HP 9000 series 300 or 400 running HP-UX@. HP-UX version 8.0 has a bug in the assembler that prevents compilation of GCC@. This Index: gcc/config/m68k/m68k.h =================================================================== --- gcc/config/m68k/m68k.h 2007-01-09 15:01:47.000000000 +0000 +++ gcc/config/m68k/m68k.h 2007-01-09 15:01:49.000000000 +0000 @@ -32,6 +32,13 @@ the Free Software Foundation; either ver # define MOTOROLA 0 /* Use the MIT assembly syntax. */ #endif +/* Handle --with-cpu default option from configure script. */ +#define OPTION_DEFAULT_SPECS \ + { "cpu", "%{!mc68000:%{!m68000:%{!m68302:%{!m68010:%{!mc68020:%{!m68020:\ +%{!m68030:%{!m68040:%{!m68020-40:%{!m68020-60:%{!m68060:%{!mcpu32:\ +%{!m68332:%{!m5200:%{!m5206e:%{!m528x:%{!m5307:%{!m5407:%{!mcfv4e:\ +-%(VALUE)}}}}}}}}}}}}}}}}}}}" }, + /* Note that some other tm.h files include this one and then override many of the definitions that relate to assembler syntax. */ Index: gcc/config/m68k/m68k-none.h =================================================================== --- gcc/config/m68k/m68k-none.h 2007-01-09 15:01:47.000000000 +0000 +++ gcc/config/m68k/m68k-none.h 2007-01-09 15:01:49.000000000 +0000 @@ -18,70 +18,11 @@ the Free Software Foundation; either ver the Free Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. */ -/* Default to m68k (m68020). */ -#ifndef TARGET_CPU_DEFAULT -#define TARGET_CPU_DEFAULT M68K_CPU_m68k -#endif - -/* These are values set by the configure script in TARGET_CPU_DEFAULT. - They are (sequential integer + (desired value for TARGET_DEFAULT) << 4). */ -#define M68K_CPU_m68k (0 + ((MASK_68020|MASK_68010|MASK_68881|MASK_BITFIELD)<<4)) -#define M68K_CPU_m68000 (1 + (0 << 4)) -#define M68K_CPU_m68010 (1 + (MASK_68010 << 4)) -#define M68K_CPU_m68020 (2 + ((MASK_68020|MASK_68010|MASK_68881|MASK_BITFIELD) << 4)) -#define M68K_CPU_m68030 (3 + ((MASK_68030|MASK_68020|MASK_68010|MASK_68881|MASK_BITFIELD) << 4)) -#define M68K_CPU_m68040 (4 + ((MASK_68040_ONLY|MASK_68020|MASK_68010|MASK_68881|MASK_BITFIELD) << 4)) -#define M68K_CPU_m68302 (5 + (0 << 4)) -#define M68K_CPU_m68332 (6 + ((MASK_68020|MASK_68010) << 4)) - -/* This is tested for below, so if target wants to override this, it - just set this first in cover file. */ -#ifndef TARGET_DEFAULT -#define TARGET_DEFAULT (TARGET_CPU_DEFAULT >> 4) -#endif -\f -/* Defaults for the various specs below. - These are collected here so we only test TARGET_CPU_DEFAULT once. */ -/* ??? CC1_CPU_DEFAULT_SPEC was copied over from the earlier version of - this file. However, it's not used anywhere here because it doesn't - seem to be necessary. */ -#if TARGET_CPU_DEFAULT == M68K_CPU_m68k || TARGET_CPU_DEFAULT == M68K_CPU_m68020 -#define ASM_CPU_DEFAULT_SPEC "-mc68020" -#define CC1_CPU_DEFAULT_SPEC "-m68020" -#else -#if TARGET_CPU_DEFAULT == M68K_CPU_m68000 -#define ASM_CPU_DEFAULT_SPEC "-mc68000" -#define CC1_CPU_DEFAULT_SPEC "-m68000" -#else -#if TARGET_CPU_DEFAULT == M68K_CPU_m68030 -#define ASM_CPU_DEFAULT_SPEC "-mc68030" -#define CC1_CPU_DEFAULT_SPEC "-m68030" -#else -#if TARGET_CPU_DEFAULT == M68K_CPU_m68040 -#define ASM_CPU_DEFAULT_SPEC "-mc68040" -#define CC1_CPU_DEFAULT_SPEC "-m68040" -#else -#if TARGET_CPU_DEFAULT == M68K_CPU_m68302 -#define ASM_CPU_DEFAULT_SPEC "-mc68302" -#define CC1_CPU_DEFAULT_SPEC "-m68302" -#else -#if TARGET_CPU_DEFAULT == M68K_CPU_m68332 -#define ASM_CPU_DEFAULT_SPEC "-mc68332" -#define CC1_CPU_DEFAULT_SPEC "-m68332" -#else -Unrecognized value in TARGET_CPU_DEFAULT. -#endif -#endif -#endif -#endif -#endif -#endif - /* Pass flags to gas indicating which type of processor we have. */ #undef ASM_SPEC #define ASM_SPEC "\ -%{m68851}%{mno-68851}%{m68881}%{mno-68881}%{msoft-float:-mno-68881} %{m68000}%{m68302}%{mc68000}%{m68010}%{m68020}%{mc68020}%{m68030}%{m68040}%{m68020-40:-mc68040} %{m68020-60:-mc68040} %{m68060}%{mcpu32}%{m68332}%{m5200}%{m5206e}%{m528x}%{m5307}%{m5407}%{mcfv4e}%{!mc68000:%{!m68000:%{!m68302:%{!m68010:%{!mc68020:%{!m68020:%{!m68030:%{!m68040:%{!m68020-40:%{!m68020-60:%{!m68060:%{!mcpu32:%{!m68332:%{!m5200:%{!m5206e:%{!m528x:%{!m5307:%{!m5407:%{!mcfv4e:%(asm_cpu_default)}}}}}}}}}}}}}}}}}}} \ +%{m68851}%{mno-68851}%{m68881}%{mno-68881}%{msoft-float:-mno-68881} %{m68000}%{m68302}%{mc68000}%{m68010}%{m68020}%{mc68020}%{m68030}%{m68040}%{m68020-40:-mc68040} %{m68020-60:-mc68040} %{m68060}%{mcpu32}%{m68332}%{m5200}%{m5206e}%{m528x}%{m5307}%{m5407}%{mcfv4e} \ %{fPIC:--pcrel} %{fpic:--pcrel} %{msep-data:--pcrel} %{mid-shared-library:--pcrel} \ " @@ -92,40 +33,4 @@ #define ASM_SPEC "\ #undef CC1_SPEC #define CC1_SPEC "" -/* This macro defines names of additional specifications to put in the specs - that can be used in various specifications like CC1_SPEC. Its definition - is an initializer with a subgrouping for each command option. - - Each subgrouping contains a string constant, that defines the - specification name, and a string constant that used by the GCC driver - program. - - Do not define this macro if it does not need to do anything. */ - -#define EXTRA_SPECS \ - { "asm_cpu_default", ASM_CPU_DEFAULT_SPEC }, \ - { "cc1_cpu_default", CC1_CPU_DEFAULT_SPEC }, \ - SUBTARGET_EXTRA_SPECS - #define CPP_SUBTARGET_SPEC "" -#define SUBTARGET_EXTRA_SPECS -\f -/* Avoid building multilib libraries for the defaults. - For targets not handled here, just build the full set of multilibs. - The default is m68k 99.9% of the time anyway. */ - -#if TARGET_CPU_DEFAULT == M68K_CPU_m68k || TARGET_CPU_DEFAULT == M68K_CPU_m68020 -#if TARGET_DEFAULT & MASK_68881 -#define MULTILIB_DEFAULTS { "m68020", "m68881" } -#else -#define MULTILIB_DEFAULTS { "m68020", "msoft-float" } -#endif -#endif - -#if TARGET_CPU_DEFAULT == M68K_CPU_m68000 || TARGET_CPU_DEFAULT == M68K_CPU_m68302 -#if TARGET_DEFAULT & MASK_68881 -#define MULTILIB_DEFAULTS { "m68000", "m68881" } -#else -#define MULTILIB_DEFAULTS { "m68000", "msoft-float" } -#endif -#endif Index: gcc/config/m68k/linux.h =================================================================== --- gcc/config/m68k/linux.h 2007-01-09 15:01:47.000000000 +0000 +++ gcc/config/m68k/linux.h 2007-01-09 15:01:49.000000000 +0000 @@ -23,15 +23,6 @@ the Free Software Foundation; either ver #undef TARGET_VERSION #define TARGET_VERSION fprintf (stderr, " (68k GNU/Linux with ELF)"); -/* Default target comes from config.gcc. */ - -#undef TARGET_DEFAULT -#ifdef TARGET_CPU_DEFAULT -#define TARGET_DEFAULT TARGET_CPU_DEFAULT -#else -#define TARGET_DEFAULT (MASK_BITFIELD|MASK_68881|MASK_68010|MASK_68020) -#endif - /* for 68k machines this only needs to be TRUE for the 68000 */ #undef STRICT_ALIGNMENT @@ -92,13 +83,7 @@ #define TARGET_OBJFMT_CPP_BUILTINS() \ while (0) #undef CPP_SPEC -#if TARGET_DEFAULT & MASK_68881 -#define CPP_SPEC \ - "%{!msoft-float:-D__HAVE_68881__} %{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT}" -#else -#define CPP_SPEC \ - "%{m68881:-D__HAVE_68881__} %{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT}" -#endif +#define CPP_SPEC "%{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT}" /* We override the ASM_SPEC from svr4.h because we must pass -m68040 down to the assembler. */ Index: gcc/config/m68k/netbsd-elf.h =================================================================== --- gcc/config/m68k/netbsd-elf.h 2007-01-09 15:01:47.000000000 +0000 +++ gcc/config/m68k/netbsd-elf.h 2007-01-09 15:01:49.000000000 +0000 @@ -31,14 +31,11 @@ #define TARGET_OS_CPP_BUILTINS() \ builtin_define ("__m68k__"); \ builtin_define ("__SVR4_ABI__"); \ builtin_define ("__motorola__"); \ + if (TARGET_HARD_FLOAT) \ + builtin_define ("__HAVE_FPU__"); \ } \ while (0) -/* Default target comes from config.gcc */ -#undef TARGET_DEFAULT -#define TARGET_DEFAULT TARGET_CPU_DEFAULT - - /* Don't try using XFmode on the 68010. */ #undef LONG_DOUBLE_TYPE_SIZE #define LONG_DOUBLE_TYPE_SIZE (TARGET_68020 ? 80 : 64) @@ -50,35 +47,15 @@ #define LIBGCC2_LONG_DOUBLE_TYPE_SIZE 80 #endif #define EXTRA_SPECS \ - { "cpp_cpu_default_spec", CPP_CPU_DEFAULT_SPEC }, \ - { "cpp_cpu_spec", CPP_CPU_SPEC }, \ - { "cpp_fpu_spec", CPP_FPU_SPEC }, \ - { "asm_default_spec", ASM_DEFAULT_SPEC }, \ - { "netbsd_cpp_spec", NETBSD_CPP_SPEC }, \ { "netbsd_entry_point", NETBSD_ENTRY_POINT }, -#define CPP_CPU_SPEC \ - "%(cpp_cpu_default_spec)" - - #undef TARGET_VERSION -#if TARGET_DEFAULT & MASK_68020 -#define TARGET_VERSION fprintf (stderr, " (NetBSD/m68k ELF)"); -#define CPP_CPU_DEFAULT_SPEC "%{!m680*:-D__mc68020__}" -#define ASM_DEFAULT_SPEC "%{!m680*:-m68020}" -#else -#define TARGET_VERSION fprintf (stderr, " (NetBSD/68010 ELF)"); -#define CPP_CPU_DEFAULT_SPEC "%{!m680*:-D__mc68010__}" -#define ASM_DEFAULT_SPEC "%{!m680*:-m68010}" -#endif - - -#if TARGET_DEFAULT & MASK_68881 -#define CPP_FPU_SPEC "%{!msoft-float:-D__HAVE_68881__ -D__HAVE_FPU__}" -#else -#define CPP_FPU_SPEC "%{m68881:-D__HAVE_68881__ -D__HAVE_FPU__}" -#endif +#define TARGET_VERSION \ + fprintf (stderr, \ + TARGET_68010 \ + ? " (NetBSD/68010 ELF)" \ + : " (NetBSD/m68k ELF)"); /* Provide a CPP_SPEC appropriate for NetBSD m68k targets. Currently we @@ -86,8 +63,7 @@ #define CPP_FPU_SPEC "%{m68881:-D__HAVE_ whether or not use of the FPU is allowed. */ #undef CPP_SPEC -#define CPP_SPEC \ - "%(netbsd_cpp_spec) %(cpp_cpu_spec) %(cpp_fpu_spec)" +#define CPP_SPEC NETBSD_CPP_SPEC /* Provide an ASM_SPEC appropriate for NetBSD m68k ELF targets. We pass @@ -95,9 +71,8 @@ #define CPP_SPEC \ #undef ASM_SPEC #define ASM_SPEC \ - "%(asm_default_spec) \ - %{m68010} %{m68020} %{m68030} %{m68040} %{m68060} \ - %{fpic|fpie:-k} %{fPIC|fPIE:-k -K}" + "%{m68010} %{m68020} %{m68030} %{m68040} %{m68060} \ + %{fpic|fpie:-k} %{fPIC|fPIE:-k -K}" #define AS_NEEDS_DASH_FOR_PIPED_INPUT Index: gcc/config/m68k/m68k.c =================================================================== --- gcc/config/m68k/m68k.c 2007-01-09 15:01:47.000000000 +0000 +++ gcc/config/m68k/m68k.c 2007-01-09 15:01:49.000000000 +0000 @@ -176,7 +176,7 @@ #define TARGET_ASM_CAN_OUTPUT_MI_THUNK d #define TARGET_ASM_FILE_START_APP_OFF true #undef TARGET_DEFAULT_TARGET_FLAGS -#define TARGET_DEFAULT_TARGET_FLAGS (TARGET_DEFAULT | MASK_STRICT_ALIGNMENT) +#define TARGET_DEFAULT_TARGET_FLAGS (MASK_STRICT_ALIGNMENT|MASK_68881) #undef TARGET_HANDLE_OPTION #define TARGET_HANDLE_OPTION m68k_handle_option Index: gcc/config/m68k/m68k.md =================================================================== --- gcc/config/m68k/m68k.md 2007-01-09 15:01:47.000000000 +0000 +++ gcc/config/m68k/m68k.md 2007-01-09 15:01:49.000000000 +0000 @@ -90,8 +90,7 @@ ;;- issues of excess precision accumulating in the extended registers. ;;- By default, GCC does not use these instructions, since such code will ;;- not run on an '030. To use these instructions, use the -m68040-only -;;- switch. By changing TARGET_DEFAULT to include TARGET_68040_ONLY, -;;- you can make these instructions the default. +;;- switch. ;;- These new instructions aren't directly in the md. They are brought ;;- into play by defining "%$" and "%&" to expand to "s" and "d" rather ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 8/63] Share ASM_SPEC code between targets 2007-01-10 10:45 ` [ColdFire 7/63] Default target selection and --with-cpu support Richard Sandiford @ 2007-01-10 10:46 ` Richard Sandiford 2007-01-10 10:54 ` [ColdFire 9/63] Add -mcpu, -march, -mtune, and related options Richard Sandiford 2007-01-10 18:10 ` [ColdFire 8/63] Share ASM_SPEC code between targets Jeffrey Law 2007-01-10 18:09 ` [ColdFire 7/63] Default target selection and --with-cpu support Jeffrey Law 1 sibling, 2 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 10:46 UTC (permalink / raw) To: gcc-patches Each m68k subtarget has its own ASM_SPEC to pass down target selection options. Some of these specs are more exhaustive than others. This patch defines an %(asm_cpu_spec) which can be used by all targets, and which passes down all known target selection options. The patch is needed by the forthcoming -mcpu=* and -march=* support. Richard gcc/ 200x-xx-xx Richard Sandiford <richard@codesourcery.com> Nathan Sidwell <nathan@codesourcery.com> * config/m68k/m68k.h (ASM_CPU_SPEC, ASM_SPEC, EXTRA_SPECS) (SUBTARGET_EXTRA_SPECS): New macros. * config/m68k/linux.h (ASM_SPEC): Remove CPU flags; use %(asm_cpu_spec) instead. * config/m68k/m68k-none.h (ASM_SPEC): Likewise. * config/m68k/openbsd.h (ASM_SPEC): Likewise. * config/m68k/netbsd-elf.h (ASM_SPEC): Likewise. (EXTRA_SPECS): Rename to... (SUBTARGET_EXTRA_SPECS): ...this. Index: gcc/config/m68k/m68k.h =================================================================== --- gcc/config/m68k/m68k.h 2007-01-09 15:01:49.000000000 +0000 +++ gcc/config/m68k/m68k.h 2007-01-09 15:01:51.000000000 +0000 @@ -39,6 +39,25 @@ #define OPTION_DEFAULT_SPECS \ %{!m68332:%{!m5200:%{!m5206e:%{!m528x:%{!m5307:%{!m5407:%{!mcfv4e:\ -%(VALUE)}}}}}}}}}}}}}}}}}}}" }, +/* Pass flags to gas indicating which type of processor we have. This + can be simplified when we can rely on the assembler supporting .cpu + and .arch directives. */ + +#define ASM_CPU_SPEC "\ +%{m68851}%{mno-68851} %{m68881}%{mno-68881} %{msoft-float:-mno-float} \ +%{m68000}%{m68302}%{mc68000}%{m68010}%{m68020}%{mc68020}%{m68030}\ +%{m68040}%{m68020-40:-m68040}%{m68020-60:-m68040}\ +%{m68060}%{mcpu32}%{m68332}%{m5200}%{m5206e}%{m528x}%{m5307}%{m5407}%{mcfv4e}\ +" + +#define ASM_SPEC "%(asm_cpu_spec)" + +#define EXTRA_SPECS \ + { "asm_cpu_spec", ASM_CPU_SPEC }, \ + SUBTARGET_EXTRA_SPECS + +#define SUBTARGET_EXTRA_SPECS + /* Note that some other tm.h files include this one and then override many of the definitions that relate to assembler syntax. */ Index: gcc/config/m68k/linux.h =================================================================== --- gcc/config/m68k/linux.h 2007-01-09 15:01:49.000000000 +0000 +++ gcc/config/m68k/linux.h 2007-01-09 15:01:51.000000000 +0000 @@ -23,6 +23,11 @@ the Free Software Foundation; either ver #undef TARGET_VERSION #define TARGET_VERSION fprintf (stderr, " (68k GNU/Linux with ELF)"); +/* Add %(asm_cpu_spec) to the svr4.h definition of ASM_SPEC. */ +#undef ASM_SPEC +#define ASM_SPEC \ + "%(asm_cpu_spec) %{v:-V} %{Qy:} %{!Qn:-Qy} %{n} %{T} %{Ym,*} %{Yd,*}" + /* for 68k machines this only needs to be TRUE for the 68000 */ #undef STRICT_ALIGNMENT @@ -85,13 +90,6 @@ #define TARGET_OBJFMT_CPP_BUILTINS() \ #undef CPP_SPEC #define CPP_SPEC "%{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT}" -/* We override the ASM_SPEC from svr4.h because we must pass -m68040 down - to the assembler. */ -#undef ASM_SPEC -#define ASM_SPEC \ - "%{v:-V} %{Qy:} %{!Qn:-Qy} %{n} %{T} %{Ym,*} %{Yd,*} %{Wa,*:%*} \ -%{m68040} %{m68060:-m68040}" - /* Provide a LINK_SPEC appropriate for GNU/Linux. Here we provide support for the special GCC options -static and -shared, which allow us to link things in one of these three modes by applying the appropriate Index: gcc/config/m68k/m68k-none.h =================================================================== --- gcc/config/m68k/m68k-none.h 2007-01-09 15:01:49.000000000 +0000 +++ gcc/config/m68k/m68k-none.h 2007-01-09 15:01:51.000000000 +0000 @@ -18,13 +18,9 @@ the Free Software Foundation; either ver the Free Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. */ -/* Pass flags to gas indicating which type of processor we have. */ - #undef ASM_SPEC -#define ASM_SPEC "\ -%{m68851}%{mno-68851}%{m68881}%{mno-68881}%{msoft-float:-mno-68881} %{m68000}%{m68302}%{mc68000}%{m68010}%{m68020}%{mc68020}%{m68030}%{m68040}%{m68020-40:-mc68040} %{m68020-60:-mc68040} %{m68060}%{mcpu32}%{m68332}%{m5200}%{m5206e}%{m528x}%{m5307}%{m5407}%{mcfv4e} \ -%{fPIC:--pcrel} %{fpic:--pcrel} %{msep-data:--pcrel} %{mid-shared-library:--pcrel} \ -" +#define ASM_SPEC "%(asm_cpu_spec) %{fPIC:--pcrel} %{fpic:--pcrel} \ + %{msep-data:--pcrel} %{mid-shared-library:--pcrel}" /* cc1/cc1plus always receives all the -m flags. If the specs strings above are consistent with the flags in m68k.opt, there should be no need for Index: gcc/config/m68k/openbsd.h =================================================================== --- gcc/config/m68k/openbsd.h 2007-01-09 15:01:42.000000000 +0000 +++ gcc/config/m68k/openbsd.h 2007-01-09 15:01:51.000000000 +0000 @@ -34,9 +34,8 @@ #define TARGET_OS_CPP_BUILTINS() \ #undef CPP_SPEC #define CPP_SPEC "%{!msoft-float:-D__HAVE_68881__ -D__HAVE_FPU__} %{posix:-D_POSIX_SOURCE} %{pthread:-D_POSIX_THREADS}" -/* m68k as needs to know about the processor subtype. */ #undef ASM_SPEC -#define ASM_SPEC "%{m68030} %{m68040} %{m68060} %{fpic|fpie:-k} %{fPIC|fPIE:-k -K}" +#define ASM_SPEC "%(asm_cpu_spec) %{fpic|fpie:-k} %{fPIC|fPIE:-k -K}" #define AS_NEEDS_DASH_FOR_PIPED_INPUT Index: gcc/config/m68k/netbsd-elf.h =================================================================== --- gcc/config/m68k/netbsd-elf.h 2007-01-09 15:01:49.000000000 +0000 +++ gcc/config/m68k/netbsd-elf.h 2007-01-09 15:01:51.000000000 +0000 @@ -46,7 +46,8 @@ #define LIBGCC2_LONG_DOUBLE_TYPE_SIZE 64 #define LIBGCC2_LONG_DOUBLE_TYPE_SIZE 80 #endif -#define EXTRA_SPECS \ +#undef SUBTARGET_EXTRA_SPECS +#define SUBTARGET_EXTRA_SPECS \ { "netbsd_entry_point", NETBSD_ENTRY_POINT }, @@ -66,13 +67,11 @@ #define TARGET_VERSION \ #define CPP_SPEC NETBSD_CPP_SPEC -/* Provide an ASM_SPEC appropriate for NetBSD m68k ELF targets. We pass - on some CPU options, as well as PIC code generation options. */ +/* Provide an ASM_SPEC appropriate for NetBSD m68k ELF targets. We need + to passn PIC code generation options. */ #undef ASM_SPEC -#define ASM_SPEC \ - "%{m68010} %{m68020} %{m68030} %{m68040} %{m68060} \ - %{fpic|fpie:-k} %{fPIC|fPIE:-k -K}" +#define ASM_SPEC "%(asm_cpu_spec) %{fpic|fpie:-k} %{fPIC|fPIE:-k -K}" #define AS_NEEDS_DASH_FOR_PIPED_INPUT ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 9/63] Add -mcpu, -march, -mtune, and related options 2007-01-10 10:46 ` [ColdFire 8/63] Share ASM_SPEC code between targets Richard Sandiford @ 2007-01-10 10:54 ` Richard Sandiford 2007-01-10 10:55 ` [ColdFire 10/63] Rename TARGET_68040_ONLY to TARGET_68040 Richard Sandiford ` (3 more replies) 2007-01-10 18:10 ` [ColdFire 8/63] Share ASM_SPEC code between targets Jeffrey Law 1 sibling, 4 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 10:54 UTC (permalink / raw) To: gcc-patches Freescale have brought out many different ColdFire devices (60 are named in this patch) and it's getting increasingly difficult for users to know which generic gcc option applies to which specific device. It therefore seemed like a good idea to have an option for every known device and leave the classification up to gcc. So far, the m68k port has used separate -m options for each target, but having 60 separate -m options wasn't very appealing. This patch therefore follows other ports by adding a -mcpu= option. For consistency, it also adds an -march option to select an ISA by name and a -mtune option to tune for a specific microarchitecture. m68k_handle_option maps the old -m options to a combination of these new ones. Some ISA A parts support hardware division while others don't. For example, the 5206 doesn't have it but the 5206e does. Thus -march=* is not enough on its own to specify an ISA, and the patch adds a separate -mdiv option too. (Use of this instruction is already controlled by a separate target mask called MASK_CF_HWDIV.) On the same theme, the patch adds an -mhard-float option to accompany the existing -msoft-float option. -mhard-float is a synonym for -m68881 on 680x0 targets, but it allows direct control of floating-point instructions on ColdFire targets too. The patch renames the associated MASK_* accordingly. (Note that because -m68881 is synonymous with -mhard-float, it is accepted for ColdFire targets as well as 680x0 targets. I don't think that's necessarily a bad thing.) The patch allows any -mcpu=FOO option to be made the default using --with-cpu=FOO. It retains the old --with-cpu=mFOO (note the "m"!) that was the subject of an earlier patch. The patch also makes cc1's default architecture and tuning flags match the driver's, thus fixing the problem mentioned in the original --with-cpu patch. The patch replaces the ISA_* masks with an m68k_cpu variable, which is a bitfield of the features that the target supports. The patch also replaces the tuning MASK_*s with an enumeration. A new file, m68k-devices.def, lists every supported 680x0 and ColdFire device (i.e. every supported -mcpu= argument). Some of the M68K_DEVICE fields are there for the benefit of later patches. One thing that needed some care was the relationship between the architecture options and the FPU options. At the moment: -m5200 -m5206e -m528x -m5307 -m5407 -m68000 -m688332 -mcpu32 all clear MASK_68881. -m68020 leaves MASK_68881 alone. -m68020-40 -m68020-60 -m68040 -m68060 all set MASK_68881 -mcfv4e clears MASK_68881 and sets MASK_CFV4E (which controls TARGET_HARD_FLOAT). An obvious implication is that -m68020 should be orthogonal to the FPU selection, but the other architecture options shouldn't be. However, I don't that's necessarily the reason why the code is the way it is, because... The m68k-* configurations all default to hard-float 68020, and if you pass -m68020 to the m68k-* gccs, you still get hard-float code. The only configuration for which the special treatment of -m68020 makes a difference _in isolation_ is m68010-*-netbsdelf, which continues to generate soft-float code when passed -m68020. However, I doubt that the netbsd effect was a deliberate decision. It seems more logical for "m68010-*-netbsdelf-gcc -m68020" to generate the same code as m68k-*-netbsdelf-gcc, which is the equivalent 68020 configuration, and which defaults to hard-float code. Instead, I think the special -m68020 behaviour is a relic from the way the old TARGET_SWITCHES macro used to work. It was then carried over to the new .opt machinery because, when I did the .opt conversion, I wanted to preserve existing command-line semantics as much as possible. I think the decision was made that -m68040 and -m68060 should default to hard-float because the FPU is fully integrated. And in the old days, everything was handled by masks, so the masks for one option overrode the masks for earlier options. Thus "-msoft-float -m68040" actually generates hard-float code, because -m68040 sets MASK_68881. I can well imagine that it was seen as bad practice for "-msoft-float -m68020" to generate hard-float code because (a) the 68881 was a separate coprocessor and (b) -m68020 might reasonably be taken as a no-op on a configuration that defaults to 68020 code. In short, I think the code is the way it is simply so that "-msoft-float -m68020" does the same as "-m68020 -msoft-float". However, with the .opt machinery, it's now possible to make "-msoft-float -mfoo" do the same as "-mfoo -msoft-float" for every architecture option -mfoo. I think that's a good thing. If the user really wanted to override an explicit -msoft-float, I think they would use an explicit -m68881 or -mhard-float. The patch therefore stops m68k_handle_option from changing the float setting and instead makes OVERRIDE_OPTIONS use the chosen architecture to pick a default if none of -mhard-float, -m68881 and -msoft-float are given. The default for 68020 is -mhard-float, to match the existing defaults. The patch takes the same sort of approach for -mbitfield and -mdiv too. The documentation uses a table to list the supported ColdFire CPUs. This is partly to break up the long list into managable chunks, and partly for the benefit of a later patch. I apologise for the long lines here, but @multitable is sensitive to whitespace. Richard gcc/ 200x-xx-xx Julian Brown <julian@codesourcery.com> Nathan Sidwell <nathan@codesourcery.com> Richard Sandiford <richard@codesourcery.com> * config.gcc (m680[012]0-*-*, m68k*-*-*): Set m68k_cpu_ident to the -mcpu= argument associated with the --with-cpu setting. Define M68K_DEFAULT_TUNE to the default -mtune= option, if different from the one implied by the -mcpu setting. Accept --with-cpu=FOO if FOO is listed in m68k-devices.def, using mcpu=FOO as the default CPU option. Set target_cpu_default2. * doc/invoke.texi: Mention ColdFire in the introduction to the m68k options. Document the new -march, -mcpu, -mtune, -mdiv, -mno-div and -mhard-float options. Make -m68881 a synonym for -mhard-float. Document the previously-undocumented -m5206e, -m528x, -m5307 and -m5407 options. Tweak the existing option documentation for consistency. * doc/install.texi: Mention new --with-cpu arguments. * config/m68k/m68k.h (OPTION_DEFAULT_SPECS): Only use the default CPU if neither -mcpu nor -march are specified. (ASM_CPU_SPEC): Pass down -mcpu and -march options. (TARGET_CPU_CPP_BUILTINS): Set __mcfisa*__ macros from TARGET_ISA*. Set the legacy __mcf*__ cpu macros in the same way, using m68k_tune to decide between families that implement the same ISA. Use m68k_tune to set __mcfv4e__. (FL_BITFIELD, FL_68881, FL_COLDFIRE, FL_CF_HWDIV, FL_CF_MAC) (FL_CF_EMAC, FL_CF_EMAC_B, FL_CF_USP, FL_CF_FPU, FL_ISA_68000) (FL_ISA_68010, FL_ISA_68020, FL_ISA_68040, FL_ISA_A, FL_ISA_B) (FL_ISA_C, FL_ISA_MMU): New macros. (MASK_COLDFIRE): Delete. (TARGET_68010, TARGET_68020, TARGET_68040_ONLY, TARGET_COLDFIRE) (TARGET_ISAB): Redefine in terms of m68k_cpu_flags. (TARGET_68881, TARGET_COLDFIRE_FPU): Redefine in terms of m68k_fpu. (TARGET_HARD_FLOAT): Do not define here. (TARGET_ISAAPLUS, TARGET_ISAC): New macros. (TUNE_68000): New macro. (TUNE_68000_10): Redefine in terms of TUNE_68000 and TUNE_68010. (TUNE_68010, TUNE_68030, TUNE_68040, TUNE_68060, TUNE_CPU32) (TUNE_CFV2): Redefine in terms of m68k_tune. (uarch_type, target_device, fpu_type): New enums. (m68k_cpu, m68k_tune, m68k_fpu, m68k_cpu_flags): Declare. * config/m68k/m68k.c (TARGET_DEFAULT): Remove MASK_68881. (FL_FOR_isa_00, FL_FOR_isa_10, FL_FOR_isa_20, FL_FOR_isa_40) (FL_FOR_isa_cpu32, FL_FOR_isa_a, FL_FOR_isa_aplus, FL_FOR_isa_b) (FL_FOR_isa_c): New macros. (m68k_isa): New enum. (m68k_target_selection): New structure. (all_devices, all_isas, all_microarchs): New tables. (m68k_cpu_entry, m68k_arch_entry, m68k_tune_entry, m68k_cpu) (m68k_tune, m68k_fpu, m68k_cpu_flags): New variables. (MASK_ALL_CPU_BITS): Delete. (m68k_find_selection): New function. (m68k_handle_option): Handle -mcpu=, -march= and -mtune=. Map the legacy target options to a combination of the new ones. (override_options): Set m68k_cpu, m68k_tune, m68k_fpu and m68k_cpu_flags. Handle M68K_DEFAULT_TUNE. Use m68k_cpu_flags to derive default MASK_BITFIELD, MASK_CF_HWDIV and MASK_HARD_FLOAT settings. * config/m68k/m68k.opt (m5200, m5206e, m528x, m5307, m5407, mcfv4e) (m68010, m68020, m68020-40, m68020-60, m68030, m68040): Remove Mask properties. (m68881, msoft-float): Change mask from 68881 to HARD_FLOAT. (march=, mcpu=, mdiv, mhard-float, mtune=): New options. * config/m68k/m68k-devices.def: New file. Index: gcc/config.gcc =================================================================== --- gcc/config.gcc 2007-01-09 15:01:49.000000000 +0000 +++ gcc/config.gcc 2007-01-09 15:01:52.000000000 +0000 @@ -2777,13 +2777,28 @@ case "${target}" in # We always have a $with_cpu setting here. case "$with_cpu" in - "m68000" | "m68010" | "m68020" | "m68030" | "m68040" | "m68060" | "m68020-40" | "m68020-60") - # OK + "m68000" | "m68010" | "m68020" | "m68030" | "m68040" | "m68060") + m68k_cpu_ident=$with_cpu ;; - *) - echo "Unknown CPU used in --with-cpu=$with_cpu, known values:" 1>&2 - echo "m68000 m68010 m68020 m68030 m68040 m68060 m68020-40 m68020-60" 1>&2 - exit 1 + "m68020-40") + m68k_cpu_ident=m68020 + tm_defines="$tm_defines M68K_DEFAULT_TUNE=u68020_40" + ;; + "m68020-60") + m68k_cpu_ident=m68020 + tm_defines="$tm_defines M68K_DEFAULT_TUNE=u68020_60" + ;; + *) + # We need the C identifier rather than the string. + m68k_cpu_ident=`awk -v arg="\"$with_cpu\"" \ + 'BEGIN { FS="[ \t]*[,()][ \t]*" }; \ + $1 == "M68K_DEVICE" && $2 == arg { print $3 }' \ + ${srcdir}/config/m68k/m68k-devices.def` + if [ x"$m68k_cpu_ident" = x ] ; then + echo "Unknown CPU used in --with-cpu=$with_cpu" 1>&2 + exit 1 + fi + with_cpu="mcpu=$with_cpu" ;; esac ;; @@ -3042,6 +3057,10 @@ case ${target} in fi ;; + m680[012]0-*-* | m68k*-*-*) + target_cpu_default2=$m68k_cpu_ident + ;; + mips*-*-*) if test x$gnu_ld = xyes then Index: gcc/doc/invoke.texi =================================================================== --- gcc/doc/invoke.texi 2007-01-09 15:01:47.000000000 +0000 +++ gcc/doc/invoke.texi 2007-01-09 15:01:52.000000000 +0000 @@ -577,10 +577,12 @@ Objective-C and Objective-C++ Dialects}. @gccoptlist{-mcpu=@var{cpu} -msim -memregs=@var{number}} @emph{M680x0 Options} -@gccoptlist{-m68000 -m68020 -m68020-40 -m68020-60 -m68030 -m68040 @gol --m68060 -mcpu32 -m5200 -mcfv4e -m68881 -mbitfield @gol --mc68000 -mc68020 @gol --mnobitfield -mrtd -mshort -msoft-float -mpcrel @gol +@gccoptlist{-march=@var{arch} -mcpu=@var{cpu} -mtune=@var{tune} +-m68000 -m68020 -m68020-40 -m68020-60 -m68030 -m68040 @gol +-m68060 -mcpu32 -m5200 -m5206e -m528x -m5307 -m5407 @gol +-mcfv4e -mbitfield -mc68000 -mc68020 @gol +-mnobitfield -mrtd -mdiv -mno-div -mshort @gol +-mhard-float -m68881 -msoft-float -mpcrel @gol -malign-int -mstrict-align -msep-data -mno-sep-data @gol -mshared-library-id=n -mid-shared-library -mno-id-shared-library} @@ -10222,18 +10224,88 @@ Indicates that there is no OS function f @subsection M680x0 Options @cindex M680x0 options -These are the @samp{-m} options defined for the 68000 series. The default -values for these options depends on which style of 68000 was selected when -the compiler was configured; the defaults for the most common choices are -given below. +These are the @samp{-m} options defined for M680x0 and ColdFire processors. +The default settings depend on which architecture was selected when +the compiler was configured; the defaults for the most common choices +are given below. @table @gcctabopt +@item -march=@var{arch} +@opindex march +Generate code for a specific M680x0 or ColdFire instruction set +architecture. Permissible values of @var{arch} for M680x0 +architectures are: @samp{68000}, @samp{68010}, @samp{68020}, +@samp{68030}, @samp{68040}, @samp{68060} and @samp{cpu32}. ColdFire +architectures are selected according to Freescale's ISA classification +and the permissible values are: @samp{isaa}, @samp{isaaplus}, +@samp{isab} and @samp{isac}. + +gcc defines a macro @samp{__mcf@var{arch}__} whenever it is generating +code for a ColdFire target. The @var{arch} in this macro is one of the +@option{-march} arguments given above. + +When used together, @option{-march} and @option{-mtune} select code +that runs on a family of similar processors but that is optimized +for a particular microarchitecture. + +@item -mcpu=@var{cpu} +@opindex mcpu +Generate code for a specific M680x0 or ColdFire processor. +The M680x0 @var{cpu}s are: @samp{68000}, @samp{68010}, @samp{68020}, +@samp{68030}, @samp{68040}, @samp{68060}, @samp{68302}, @samp{68332} +and @samp{cpu32}. The ColdFire @var{cpu}s are given by the table +below, which also classifies the CPUs into families: + +@multitable @columnfractions 0.20 0.80 +@headitem Family @tab @samp{-mcpu} arguments +@item @samp{5206} @tab @samp{5202} @samp{5204} @samp{5206} +@item @samp{5206e} @tab @samp{5206e} +@item @samp{5208} @tab @samp{5207} @samp{5208} +@item @samp{5211a} @tab @samp{5210a} @samp{5211a} +@item @samp{5213} @tab @samp{5211} @samp{5212} @samp{5213} +@item @samp{5216} @tab @samp{5214} @samp{5216} +@item @samp{52235} @tab @samp{52230} @samp{52231} @samp{52232} @samp{52233} @samp{52234} @samp{52235} +@item @samp{5225} @tab @samp{5224} @samp{5225} +@item @samp{5235} @tab @samp{5232} @samp{5233} @samp{5234} @samp{5235} @samp{523x} +@item @samp{5249} @tab @samp{5249} +@item @samp{5250} @tab @samp{5250} +@item @samp{5271} @tab @samp{5270} @samp{5271} +@item @samp{5272} @tab @samp{5272} +@item @samp{5275} @tab @samp{5274} @samp{5275} +@item @samp{5282} @tab @samp{5280} @samp{5281} @samp{5282} @samp{528x} +@item @samp{5307} @tab @samp{5307} +@item @samp{5329} @tab @samp{5327} @samp{5328} @samp{5329} @samp{532x} +@item @samp{5373} @tab @samp{5372} @samp{5373} @samp{537x} +@item @samp{5407} @tab @samp{5407} +@item @samp{5475} @tab @samp{5470} @samp{5471} @samp{5472} @samp{5473} @samp{5474} @samp{5475} @samp{547x} @samp{5480} @samp{5481} @samp{5482} @samp{5483} @samp{5484} @samp{5485} +@end multitable + +@option{-mcpu=@var{cpu}} overrides @option{-march=@var{arch}} if +@var{arch} is compatible with @var{cpu}. Other combinations of +@option{-mcpu} and @option{-march} are rejected. + +@item -mtune=@var{tune} +@opindex mtune +Tune the code for a particular microarchitecture, within the +constraints set by @option{-march} and @option{-mcpu}. +The M680x0 microarchitectures are: @samp{68000}, @samp{68010}, +@samp{68020}, @samp{68030}, @samp{68040}, @samp{68060} +and @samp{cpu32}. The ColdFire microarchitectures +are: @samp{cfv2}, @samp{cfv3}, @samp{cfv4} and @samp{cfv4e}. + +You can also use @option{-mtune=68020-40} for code that needs +to run relatively well on 68020, 68030 and 68040 targets. +@option{-mtune=68020-60} is similar but includes 68060 targets +as well. These two options select the same tuning decisions as +@option{-m68020-40} and @option{-m68020-60} respectively. + @item -m68000 @itemx -mc68000 @opindex m68000 @opindex mc68000 Generate output for a 68000. This is the default when the compiler is configured for 68000-based systems. +It is equivalent to @option{-march=68000}. Use this option for microcontrollers with a 68000 or EC000 core, including the 68008, 68302, 68306, 68307, 68322, 68328 and 68356. @@ -10242,6 +10314,7 @@ including the 68008, 68302, 68306, 68307 @opindex m68010 Generate output for a 68010. This is the default when the compiler is configured for 68010-based systems. +It is equivalent to @option{-march=68010}. @item -m68020 @itemx -mc68020 @@ -10249,22 +10322,19 @@ when the compiler is configured for 6801 @opindex mc68020 Generate output for a 68020. This is the default when the compiler is configured for 68020-based systems. - -@item -m68881 -@opindex m68881 -Generate output containing 68881 instructions for floating point. -This is the default for most 68020 systems unless @option{--nfp} was -specified when the compiler was configured. +It is equivalent to @option{-march=68020}. @item -m68030 @opindex m68030 Generate output for a 68030. This is the default when the compiler is -configured for 68030-based systems. +configured for 68030-based systems. It is equivalent to +@option{-march=68030}. @item -m68040 @opindex m68040 Generate output for a 68040. This is the default when the compiler is -configured for 68040-based systems. +configured for 68040-based systems. It is equivalent to +@option{-march=68040}. This option inhibits the use of 68881/68882 instructions that have to be emulated by software on the 68040. Use this option if your 68040 does not @@ -10273,7 +10343,8 @@ have code to emulate those instructions. @item -m68060 @opindex m68060 Generate output for a 68060. This is the default when the compiler is -configured for 68060-based systems. +configured for 68060-based systems. It is equivalent to +@option{-march=68060}. This option inhibits the use of 68020 and 68881/68882 instructions that have to be emulated by software on the 68060. Use this option if your 68060 @@ -10283,6 +10354,7 @@ does not have code to emulate those inst @opindex mcpu32 Generate output for a CPU32. This is the default when the compiler is configured for CPU32-based systems. +It is equivalent to @option{-march=cpu32}. Use this option for microcontrollers with a CPU32 or CPU32+ core, including the 68330, 68331, 68332, 68333, 68334, @@ -10290,16 +10362,41 @@ CPU32 or CPU32+ core, including the 6833 @item -m5200 @opindex m5200 -Generate output for a 520X ``coldfire'' family cpu. This is the default +Generate output for a 520X ColdFire CPU. This is the default when the compiler is configured for 520X-based systems. +It is equivalent to @option{-mcpu=5206}, and is now deprecated +in favor of that option. Use this option for microcontroller with a 5200 core, including -the MCF5202, MCF5203, MCF5204 and MCF5202. +the MCF5202, MCF5203, MCF5204 and MCF5206. + +@item -m5206e +@opindex m5206e +Generate output for a 5206e ColdFire CPU. The option is now +deprecated in favor of the equivalent @option{-mcpu=5206e}. + +@item -m528x +@opindex m528x +Generate output for a member of the ColdFire 528X family. +The option is now deprecated in favor of the equivalent +@option{-mcpu=528x}. + +@item -m5307 +@opindex m5307 +Generate output for a ColdFire 5307 CPU. The option is now deprecated +in favor of the equivalent @option{-mcpu=5307}. + +@item -m5407 +@opindex m5407 +Generate output for a ColdFire 5407 CPU. The option is now deprecated +in favor of the equivalent @option{-mcpu=5407}. @item -mcfv4e @opindex mcfv4e -Generate output for a ColdFire V4e family cpu (e.g.@: 547x/548x). +Generate output for a ColdFire V4e family CPU (e.g.@: 547x/548x). This includes use of hardware floating point instructions. +The option is equivalent to @option{-mcpu=547x}, and is now +deprecated in favor of that option. @item -m68020-40 @opindex m68020-40 @@ -10308,6 +10405,8 @@ This results in code which can run relat 68020/68881 or a 68030 or a 68040. The generated code does use the 68881 instructions that are emulated on the 68040. +The option is equivalent to @option{-march=68020} @option{-mtune=68020-40}. + @item -m68020-60 @opindex m68020-60 Generate output for a 68060, without using any of the new instructions. @@ -10315,15 +10414,34 @@ This results in code which can run relat 68020/68881 or a 68030 or a 68040. The generated code does use the 68881 instructions that are emulated on the 68060. +The option is equivalent to @option{-march=68020} @option{-mtune=68020-60}. + +@item -mhard-float +@itemx -m68881 +@opindex mhard-float +@opindex m68881 +Generate floating-point instructions. This is the default for 68020 +and above, and for ColdFire devices that have an FPU. + @item -msoft-float @opindex msoft-float -Generate output containing library calls for floating point. -@strong{Warning:} the requisite libraries are not available for all m68k -targets. Normally the facilities of the machine's usual C compiler are -used, but this can't be done directly in cross-compilation. You must -make your own arrangements to provide suitable library functions for -cross-compilation. The embedded targets @samp{m68k-*-aout} and -@samp{m68k-*-coff} do provide software floating point support. +Do not generate floating-point instructions; use library calls instead. +This is the default for 68000, 68010, and 68832 targets. It is also +the default for ColdFire devices that have no FPU. + +@item -mdiv +@itemx -mno-div +@opindex mdiv +@opindex mno-div +Generate (do not generate) ColdFire hardware divide and remainder +instructions. If @option{-march} is used without @option{-mcpu}, +the default is ``on'' for ColdFire architectures and ``off'' for M680x0 +architectures. Otherwise, the default is taken from the target CPU +(either the default CPU, or the one specified by @option{-mcpu}). For +example, the default is ``off'' for @option{-mcpu=5206} and ``on'' for +@option{-mcpu=5206e}. + +gcc defines the macro @samp{__mcfhwdiv__} when this option is enabled. @item -mshort @opindex mshort Index: gcc/doc/install.texi =================================================================== --- gcc/doc/install.texi 2007-01-09 15:01:49.000000000 +0000 +++ gcc/doc/install.texi 2007-01-09 15:01:52.000000000 +0000 @@ -3388,9 +3388,9 @@ applications. There are no standard Uni @end html @heading @anchor{m68k-*-*}m68k-*-* You can specify a default target using @option{--with-cpu=@var{target}}. -The recognized values for @var{target} are: @samp{m68000}, @samp{m68010}, -@samp{m68020}, @samp{m68030}, @samp{m68040}, @samp{m68060}, @samp{m68020-40} -and @samp{m68020-60}. +This @var{target} can either be a @option{-mcpu} argument or one of the +following values: @samp{m68000}, @samp{m68010}, @samp{m68020}, @samp{m68030}, +@samp{m68040}, @samp{m68060}, @samp{m68020-40} and @samp{m68020-60}. @heading @anchor{m68k-hp-hpux}m68k-hp-hpux HP 9000 series 300 or 400 running HP-UX@. HP-UX version 8.0 has a bug in Index: gcc/config/m68k/m68k.h =================================================================== --- gcc/config/m68k/m68k.h 2007-01-09 15:01:51.000000000 +0000 +++ gcc/config/m68k/m68k.h 2007-01-09 15:01:52.000000000 +0000 @@ -37,7 +37,7 @@ #define OPTION_DEFAULT_SPECS \ { "cpu", "%{!mc68000:%{!m68000:%{!m68302:%{!m68010:%{!mc68020:%{!m68020:\ %{!m68030:%{!m68040:%{!m68020-40:%{!m68020-60:%{!m68060:%{!mcpu32:\ %{!m68332:%{!m5200:%{!m5206e:%{!m528x:%{!m5307:%{!m5407:%{!mcfv4e:\ --%(VALUE)}}}}}}}}}}}}}}}}}}}" }, +%{!mcpu=*:%{!march=*:-%(VALUE)}}}}}}}}}}}}}}}}}}}}}" }, /* Pass flags to gas indicating which type of processor we have. This can be simplified when we can rely on the assembler supporting .cpu @@ -48,6 +48,7 @@ #define ASM_CPU_SPEC "\ %{m68000}%{m68302}%{mc68000}%{m68010}%{m68020}%{mc68020}%{m68030}\ %{m68040}%{m68020-40:-m68040}%{m68020-60:-m68040}\ %{m68060}%{mcpu32}%{m68332}%{m5200}%{m5206e}%{m528x}%{m5307}%{m5407}%{mcfv4e}\ +%{mcpu=*:-mcpu=%*}%{march=*:-march=%*}\ " #define ASM_SPEC "%(asm_cpu_spec)" @@ -100,30 +101,50 @@ #define TARGET_CPU_CPP_BUILTINS() \ builtin_define_std ("mcpu32"); \ } \ if (TARGET_COLDFIRE) \ - builtin_define ("__mcoldfire__"); \ - if (TARGET_5200) \ - builtin_define ("__mcf5200__"); \ - if (TARGET_528x) \ { \ - builtin_define ("__mcf528x__"); \ - builtin_define ("__mcf5200__"); \ - } \ - if (TARGET_CFV3) \ - { \ - builtin_define ("__mcf5300__"); \ - builtin_define ("__mcf5307__"); \ - } \ - if (TARGET_CFV4) \ - { \ - builtin_define ("__mcf5400__"); \ - builtin_define ("__mcf5407__"); \ - } \ - if (TARGET_CFV4E) \ - { \ - builtin_define ("__mcfv4e__"); \ + builtin_define ("__mcoldfire__"); \ + if (TARGET_ISAC) \ + builtin_define ("__mcfisac__"); \ + else if (TARGET_ISAB) \ + { \ + builtin_define ("__mcfisab__"); \ + /* ISA_B: Legacy 5407 defines. */ \ + builtin_define ("__mcf5400__"); \ + builtin_define ("__mcf5407__"); \ + } \ + else if (TARGET_ISAAPLUS) \ + { \ + builtin_define ("__mcfisaaplus__"); \ + /* ISA_A+: legacy defines. */ \ + builtin_define ("__mcf528x__"); \ + builtin_define ("__mcf5200__"); \ + } \ + else \ + { \ + builtin_define ("__mcfisaa__"); \ + /* ISA_A: legacy defines. */ \ + switch (m68k_tune) \ + { \ + case ucfv2: \ + builtin_define ("__mcf5200__"); \ + break; \ + \ + case ucfv3: \ + builtin_define ("__mcf5307__"); \ + builtin_define ("__mcf5300__"); \ + break; \ + \ + default: \ + break; \ + } \ + } \ + if (m68k_tune == ucfv4e) \ + builtin_define ("__mcfv4e__"); \ } \ + \ if (TARGET_CF_HWDIV) \ builtin_define ("__mcfhwdiv__"); \ + \ builtin_assert ("cpu=m68k"); \ builtin_assert ("machine=m68k"); \ } \ @@ -139,30 +160,53 @@ #define INT_OP_DC 3 /* dc.b, dc.w, dc.l /* Set the default. */ #define INT_OP_GROUP INT_OP_DOT_WORD -/* Compile for a CPU32. A 68020 without bitfields is a good - heuristic for a CPU32. */ -#define TUNE_CPU32 (TARGET_68020 && !TARGET_BITFIELD) - -/* Is the target a ColdFire? */ -#define MASK_COLDFIRE \ - (MASK_5200 | MASK_528x | MASK_CFV3 | MASK_CFV4 | MASK_CFV4E) -#define TARGET_COLDFIRE ((target_flags & MASK_COLDFIRE) != 0) - -#define TARGET_COLDFIRE_FPU TARGET_CFV4E +/* Bit values used by m68k-devices.def to identify processor capabilities. */ +#define FL_BITFIELD (1 << 0) /* Support bitfield instructions. */ +#define FL_68881 (1 << 1) /* (Default) support for 68881/2. */ +#define FL_COLDFIRE (1 << 2) /* ColdFire processor. */ +#define FL_CF_HWDIV (1 << 3) /* ColdFire hardware divide supported. */ +#define FL_CF_MAC (1 << 4) /* ColdFire MAC unit supported. */ +#define FL_CF_EMAC (1 << 5) /* ColdFire eMAC unit supported. */ +#define FL_CF_EMAC_B (1 << 6) /* ColdFire eMAC-B unit supported. */ +#define FL_CF_USP (1 << 7) /* ColdFire User Stack Pointer supported. */ +#define FL_CF_FPU (1 << 8) /* ColdFire FPU supported. */ +#define FL_ISA_68000 (1 << 9) +#define FL_ISA_68010 (1 << 10) +#define FL_ISA_68020 (1 << 11) +#define FL_ISA_68040 (1 << 12) +#define FL_ISA_A (1 << 13) +#define FL_ISA_APLUS (1 << 14) +#define FL_ISA_B (1 << 15) +#define FL_ISA_C (1 << 16) +#define FL_MMU 0 /* Used by multilib machinery. */ + +#define TARGET_68010 ((m68k_cpu_flags & FL_ISA_68010) != 0) +#define TARGET_68020 ((m68k_cpu_flags & FL_ISA_68020) != 0) +#define TARGET_68040_ONLY ((m68k_cpu_flags & FL_ISA_68040) != 0) +#define TARGET_COLDFIRE ((m68k_cpu_flags & FL_COLDFIRE) != 0) +#define TARGET_COLDFIRE_FPU (m68k_fpu == FPUTYPE_COLDFIRE) +#define TARGET_68881 (m68k_fpu == FPUTYPE_68881) -#define TARGET_HARD_FLOAT (TARGET_68881 || TARGET_COLDFIRE_FPU) /* Size (in bytes) of FPU registers. */ #define TARGET_FP_REG_SIZE (TARGET_COLDFIRE ? 8 : 12) -#define TARGET_ISAB TARGET_CFV4 - -#define TUNE_68000_10 (!TARGET_68020 && !TARGET_COLDFIRE) -#define TUNE_68010 TARGET_68010 -#define TUNE_68030 TARGET_68030 -#define TUNE_68040 TARGET_68040 -#define TUNE_68060 TARGET_68060 +#define TARGET_ISAAPLUS ((m68k_cpu_flags & FL_ISA_APLUS) != 0) +#define TARGET_ISAB ((m68k_cpu_flags & FL_ISA_B) != 0) +#define TARGET_ISAC ((m68k_cpu_flags & FL_ISA_C) != 0) + +#define TUNE_68000 (m68k_tune == u68000) +#define TUNE_68010 (m68k_tune == u68010) +#define TUNE_68000_10 (TUNE_68000 || TUNE_68010) +#define TUNE_68030 (m68k_tune == u68030 \ + || m68k_tune == u68020_40 \ + || m68k_tune == u68020_60) +#define TUNE_68040 (m68k_tune == u68040 \ + || m68k_tune == u68020_40 \ + || m68k_tune == u68020_60) +#define TUNE_68060 (m68k_tune == u68060 || m68k_tune == u68020_60) #define TUNE_68040_60 (TUNE_68040 || TUNE_68060) -#define TUNE_CFV2 TARGET_5200 +#define TUNE_CPU32 (m68k_tune == ucpu32) +#define TUNE_CFV2 (m68k_tune == ucfv2) #define OVERRIDE_OPTIONS override_options() @@ -1104,6 +1148,47 @@ #define PRINT_OPERAND(FILE, X, CODE) pri #define PRINT_OPERAND_ADDRESS(FILE, ADDR) print_operand_address (FILE, ADDR) -/* Variables in m68k.c */ +/* Values used in the MICROARCH argument to M68K_DEVICE. */ +enum uarch_type +{ + u68000, + u68010, + u68020, + u68020_40, + u68020_60, + u68030, + u68040, + u68060, + ucpu32, + ucfv2, + ucfv3, + ucfv4, + ucfv4e, + ucfv5, + unk_arch +}; + +/* An enumeration of all supported target devices. */ +enum target_device +{ +#define M68K_DEVICE(NAME,ENUM_VALUE,FAMILY,MULTILIB,MICROARCH,ISA,FLAGS) \ + ENUM_VALUE, +#include "m68k-devices.def" +#undef M68K_DEVICE + unk_device +}; + +enum fpu_type +{ + FPUTYPE_NONE, + FPUTYPE_68881, + FPUTYPE_COLDFIRE +}; + +/* Variables in m68k.c; see there for details. */ extern const char *m68k_library_id_string; extern int m68k_last_compare_had_fp_operands; +extern enum target_device m68k_cpu; +extern enum uarch_type m68k_tune; +extern enum fpu_type m68k_fpu; +extern unsigned int m68k_cpu_flags; Index: gcc/config/m68k/m68k.c =================================================================== --- gcc/config/m68k/m68k.c 2007-01-09 15:01:49.000000000 +0000 +++ gcc/config/m68k/m68k.c 2007-01-09 15:01:52.000000000 +0000 @@ -176,7 +176,7 @@ #define TARGET_ASM_CAN_OUTPUT_MI_THUNK d #define TARGET_ASM_FILE_START_APP_OFF true #undef TARGET_DEFAULT_TARGET_FLAGS -#define TARGET_DEFAULT_TARGET_FLAGS (MASK_STRICT_ALIGNMENT|MASK_68881) +#define TARGET_DEFAULT_TARGET_FLAGS MASK_STRICT_ALIGNMENT #undef TARGET_HANDLE_OPTION #define TARGET_HANDLE_OPTION m68k_handle_option @@ -201,12 +201,152 @@ static const struct attribute_spec m68k_ struct gcc_target targetm = TARGET_INITIALIZER; \f -/* These bits are controlled by all CPU selection options. Many options - also control MASK_68881, but some (notably -m68020) leave it alone. */ +/* Base flags for 68k ISAs. */ +#define FL_FOR_isa_00 FL_ISA_68000 +#define FL_FOR_isa_10 (FL_FOR_isa_00 | FL_ISA_68010) +/* FL_68881 controls the default setting of -m68881. gcc has traditionally + generated 68881 code for 68020 and 68030 targets unless explicitly told + not to. */ +#define FL_FOR_isa_20 (FL_FOR_isa_10 | FL_ISA_68020 \ + | FL_BITFIELD | FL_68881) +#define FL_FOR_isa_40 (FL_FOR_isa_20 | FL_ISA_68040) +#define FL_FOR_isa_cpu32 (FL_FOR_isa_10 | FL_ISA_68020) + +/* Base flags for ColdFire ISAs. */ +#define FL_FOR_isa_a (FL_COLDFIRE | FL_ISA_A) +#define FL_FOR_isa_aplus (FL_FOR_isa_a | FL_ISA_APLUS | FL_CF_USP) +/* Note ISA_B doesn't necessarily include USP (user stack pointer) support. */ +#define FL_FOR_isa_b (FL_FOR_isa_a | FL_ISA_B | FL_CF_HWDIV) +#define FL_FOR_isa_c (FL_FOR_isa_b | FL_ISA_C | FL_CF_USP) + +enum m68k_isa +{ + /* Traditional 68000 instruction sets. */ + isa_00, + isa_10, + isa_20, + isa_40, + isa_cpu32, + /* ColdFire instruction set variants. */ + isa_a, + isa_aplus, + isa_b, + isa_c, + isa_max +}; + +/* Information about one of the -march, -mcpu or -mtune arguments. */ +struct m68k_target_selection +{ + /* The argument being described. */ + const char *name; + + /* For -mcpu, this is the device selected by the option. + For -mtune and -march, it is a representative device + for the microarchitecture or ISA respectively. */ + enum target_device device; + + /* The M68K_DEVICE fields associated with DEVICE. See the comment + in m68k-devices.def for details. FAMILY is only valid for -mcpu. */ + const char *family; + enum uarch_type microarch; + enum m68k_isa isa; + unsigned long flags; +}; + +/* A list of all devices in m68k-devices.def. Used for -mcpu selection. */ +static const struct m68k_target_selection all_devices[] = +{ +#define M68K_DEVICE(NAME,ENUM_VALUE,FAMILY,MULTILIB,MICROARCH,ISA,FLAGS) \ + { NAME, ENUM_VALUE, FAMILY, u##MICROARCH, ISA, FLAGS | FL_FOR_##ISA }, +#include "m68k-devices.def" +#undef M68K_DEVICE + { NULL, unk_device, NULL, unk_arch, isa_max, 0 } +}; + +/* A list of all ISAs, mapping each one to a representative device. + Used for -march selection. */ +static const struct m68k_target_selection all_isas[] = +{ + { "68000", m68000, NULL, u68000, isa_00, FL_FOR_isa_00 }, + { "68010", m68010, NULL, u68010, isa_10, FL_FOR_isa_10 }, + { "68020", m68020, NULL, u68020, isa_20, FL_FOR_isa_20 }, + { "68030", m68030, NULL, u68030, isa_20, FL_FOR_isa_20 }, + { "68040", m68040, NULL, u68040, isa_40, FL_FOR_isa_40 }, + { "68060", m68060, NULL, u68060, isa_40, FL_FOR_isa_40 }, + { "cpu32", cpu32, NULL, ucpu32, isa_20, FL_FOR_isa_cpu32 }, + { "isaa", mcf5206e, NULL, ucfv2, isa_a, (FL_FOR_isa_a + | FL_CF_HWDIV) }, + { "isaaplus", mcf5271, NULL, ucfv2, isa_aplus, (FL_FOR_isa_aplus + | FL_CF_HWDIV) }, + { "isab", mcf5407, NULL, ucfv4, isa_b, FL_FOR_isa_b }, + { "isac", unk_device, NULL, ucfv4, isa_c, (FL_FOR_isa_c + | FL_CF_FPU + | FL_CF_EMAC) }, + { NULL, unk_device, NULL, unk_arch, isa_max, 0 } +}; + +/* A list of all microarchitectures, mapping each one to a representative + device. Used for -mtune selection. */ +static const struct m68k_target_selection all_microarchs[] = +{ + { "68000", m68000, NULL, u68000, isa_00, FL_FOR_isa_00 }, + { "68010", m68010, NULL, u68010, isa_10, FL_FOR_isa_10 }, + { "68020", m68020, NULL, u68020, isa_20, FL_FOR_isa_20 }, + { "68020-40", m68020, NULL, u68020_40, isa_20, FL_FOR_isa_20 }, + { "68020-60", m68020, NULL, u68020_60, isa_20, FL_FOR_isa_20 }, + { "68030", m68030, NULL, u68030, isa_20, FL_FOR_isa_20 }, + { "68040", m68040, NULL, u68040, isa_40, FL_FOR_isa_40 }, + { "68060", m68060, NULL, u68060, isa_40, FL_FOR_isa_40 }, + { "cpu32", cpu32, NULL, ucpu32, isa_20, FL_FOR_isa_cpu32 }, + { "cfv2", mcf5206, NULL, ucfv2, isa_a, FL_FOR_isa_a }, + { "cfv3", mcf5307, NULL, ucfv3, isa_a, (FL_FOR_isa_a + | FL_CF_HWDIV) }, + { "cfv4", mcf5407, NULL, ucfv4, isa_b, FL_FOR_isa_b }, + { "cfv4e", mcf547x, NULL, ucfv4e, isa_b, (FL_FOR_isa_b + | FL_CF_USP + | FL_CF_EMAC + | FL_CF_FPU) }, + { NULL, unk_device, NULL, unk_arch, isa_max, 0 } +}; +\f +/* The entries associated with the -mcpu, -march and -mtune settings, + or null for options that have not been used. */ +const struct m68k_target_selection *m68k_cpu_entry; +const struct m68k_target_selection *m68k_arch_entry; +const struct m68k_target_selection *m68k_tune_entry; + +/* Which CPU we are generating code for. */ +enum target_device m68k_cpu; + +/* Which microarchitecture to tune for. */ +enum uarch_type m68k_tune; -#define MASK_ALL_CPU_BITS \ - (MASK_COLDFIRE | MASK_CF_HWDIV | MASK_68060 | MASK_68040 \ - | MASK_68040_ONLY | MASK_68030 | MASK_68020 | MASK_68010 | MASK_BITFIELD) +/* Which FPU to use. */ +enum fpu_type m68k_fpu; + +/* The set of FL_* flags that apply to the target processor. */ +unsigned int m68k_cpu_flags; +\f +/* See whether TABLE has an entry with name NAME. Return true and + store the entry in *ENTRY if so, otherwise return false and + leave *ENTRY alone. */ + +static bool +m68k_find_selection (const struct m68k_target_selection **entry, + const struct m68k_target_selection *table, + const char *name) +{ + size_t i; + + for (i = 0; table[i].name; i++) + if (strcmp (table[i].name, name) == 0) + { + *entry = table + i; + return true; + } + return false; +} /* Implement TARGET_HANDLE_OPTION. */ @@ -215,90 +355,69 @@ m68k_handle_option (size_t code, const c { switch (code) { + case OPT_march_: + return m68k_find_selection (&m68k_arch_entry, all_isas, arg); + + case OPT_mcpu_: + return m68k_find_selection (&m68k_cpu_entry, all_devices, arg); + + case OPT_mtune_: + return m68k_find_selection (&m68k_tune_entry, all_microarchs, arg); + case OPT_m5200: - target_flags &= ~(MASK_ALL_CPU_BITS | MASK_68881); - target_flags |= MASK_5200; - return true; + return m68k_find_selection (&m68k_cpu_entry, all_devices, "5206"); case OPT_m5206e: - target_flags &= ~(MASK_ALL_CPU_BITS | MASK_68881); - target_flags |= MASK_5200 | MASK_CF_HWDIV; - return true; + return m68k_find_selection (&m68k_cpu_entry, all_devices, "5206e"); case OPT_m528x: - target_flags &= ~(MASK_ALL_CPU_BITS | MASK_68881); - target_flags |= MASK_528x | MASK_CF_HWDIV; - return true; + return m68k_find_selection (&m68k_cpu_entry, all_devices, "528x"); case OPT_m5307: - target_flags &= ~(MASK_ALL_CPU_BITS | MASK_68881); - target_flags |= MASK_CFV3 | MASK_CF_HWDIV; - return true; + return m68k_find_selection (&m68k_cpu_entry, all_devices, "5307"); case OPT_m5407: - target_flags &= ~(MASK_ALL_CPU_BITS | MASK_68881); - target_flags |= MASK_CFV4 | MASK_CF_HWDIV; - return true; + return m68k_find_selection (&m68k_cpu_entry, all_devices, "5407"); case OPT_mcfv4e: - target_flags &= ~(MASK_ALL_CPU_BITS | MASK_68881); - target_flags |= MASK_CFV4 | MASK_CF_HWDIV | MASK_CFV4E; - return true; + return m68k_find_selection (&m68k_cpu_entry, all_devices, "547x"); case OPT_m68000: case OPT_mc68000: - target_flags &= ~(MASK_ALL_CPU_BITS | MASK_68881); - return true; + return m68k_find_selection (&m68k_cpu_entry, all_devices, "68000"); case OPT_m68010: - target_flags &= ~(MASK_ALL_CPU_BITS | MASK_68881); - target_flags |= MASK_68010; - return true; + return m68k_find_selection (&m68k_cpu_entry, all_devices, "68010"); case OPT_m68020: case OPT_mc68020: - target_flags &= ~MASK_ALL_CPU_BITS; - target_flags |= MASK_68010 | MASK_68020 | MASK_BITFIELD; - return true; + return m68k_find_selection (&m68k_cpu_entry, all_devices, "68020"); case OPT_m68020_40: - target_flags &= ~MASK_ALL_CPU_BITS; - target_flags |= (MASK_BITFIELD | MASK_68881 | MASK_68010 - | MASK_68020 | MASK_68040); - return true; + return (m68k_find_selection (&m68k_tune_entry, all_microarchs, + "68020-40") + && m68k_find_selection (&m68k_cpu_entry, all_devices, "68020")); case OPT_m68020_60: - target_flags &= ~MASK_ALL_CPU_BITS; - target_flags |= (MASK_BITFIELD | MASK_68881 | MASK_68010 - | MASK_68020 | MASK_68040 | MASK_68060); - return true; + return (m68k_find_selection (&m68k_tune_entry, all_microarchs, + "68020-60") + && m68k_find_selection (&m68k_cpu_entry, all_devices, "68020")); case OPT_m68030: - target_flags &= ~MASK_ALL_CPU_BITS; - target_flags |= MASK_68010 | MASK_68020 | MASK_68030 | MASK_BITFIELD; - return true; + return m68k_find_selection (&m68k_cpu_entry, all_devices, "68030"); case OPT_m68040: - target_flags &= ~MASK_ALL_CPU_BITS; - target_flags |= (MASK_68010 | MASK_68020 | MASK_68881 | MASK_BITFIELD - | MASK_68040_ONLY | MASK_68040); - return true; + return m68k_find_selection (&m68k_cpu_entry, all_devices, "68040"); case OPT_m68060: - target_flags &= ~MASK_ALL_CPU_BITS; - target_flags |= (MASK_68010 | MASK_68020 | MASK_68881 | MASK_BITFIELD - | MASK_68040_ONLY | MASK_68060); - return true; + return m68k_find_selection (&m68k_cpu_entry, all_devices, "68060"); case OPT_m68302: - target_flags &= ~(MASK_ALL_CPU_BITS | MASK_68881); - return true; + return m68k_find_selection (&m68k_cpu_entry, all_devices, "68302"); case OPT_m68332: case OPT_mcpu32: - target_flags &= ~(MASK_ALL_CPU_BITS | MASK_68881); - target_flags |= MASK_68010 | MASK_68020; - return true; + return m68k_find_selection (&m68k_cpu_entry, all_devices, "68332"); case OPT_mshared_library_id_: if (value > MAX_LIBRARY_ID) @@ -325,6 +444,68 @@ m68k_handle_option (size_t code, const c void override_options (void) { + const struct m68k_target_selection *entry; + unsigned long target_mask; + + /* User can choose: + + -mcpu= + -march= + -mtune= + + -march=ARCH should generate code that runs any processor + implementing architecture ARCH. -mcpu=CPU should override -march + and should generate code that runs on processor CPU, making free + use of any instructions that CPU understands. -mtune=UARCH applies + on top of -mcpu or -march and optimises the code for UARCH. It does + not change the target architecture. */ + if (m68k_cpu_entry) + { + /* Complain if the -march setting is for a different microarchitecture, + or includes flags that the -mcpu setting doesn't. */ + if (m68k_arch_entry + && (m68k_arch_entry->microarch != m68k_cpu_entry->microarch + || (m68k_arch_entry->flags & ~m68k_cpu_entry->flags) != 0)) + warning (0, "-mcpu=%s conflicts with -march=%s", + m68k_cpu_entry->name, m68k_arch_entry->name); + + entry = m68k_cpu_entry; + } + else + entry = m68k_arch_entry; + + if (!entry) + entry = all_devices + TARGET_CPU_DEFAULT; + + m68k_cpu_flags = entry->flags; + + /* Use the architecture setting to derive default values for + certain flags. */ + target_mask = 0; + if ((m68k_cpu_flags & FL_BITFIELD) != 0) + target_mask |= MASK_BITFIELD; + if ((m68k_cpu_flags & FL_CF_HWDIV) != 0) + target_mask |= MASK_CF_HWDIV; + if ((m68k_cpu_flags & (FL_68881 | FL_CF_FPU)) != 0) + target_mask |= MASK_HARD_FLOAT; + target_flags |= target_mask & ~target_flags_explicit; + + /* Set the directly-usable versions of the -mcpu and -mtune settings. */ + m68k_cpu = entry->device; + if (m68k_tune_entry) + m68k_tune = m68k_tune_entry->microarch; +#ifdef M68K_DEFAULT_TUNE + else if (!m68k_cpu_entry && !m68k_arch_entry) + m68k_tune = M68K_DEFAULT_TUNE; +#endif + else + m68k_tune = entry->microarch; + + /* Set the type of FPU. */ + m68k_fpu = (!TARGET_HARD_FLOAT ? FPUTYPE_NONE + : (m68k_cpu_flags & FL_COLDFIRE) != 0 ? FPUTYPE_COLDFIRE + : FPUTYPE_68881); + /* Sanity check to ensure that msep-data and mid-sahred-library are not * both specified together. Doing so simply doesn't make sense. */ Index: gcc/config/m68k/m68k.opt =================================================================== --- gcc/config/m68k/m68k.opt 2007-01-09 15:01:47.000000000 +0000 +++ gcc/config/m68k/m68k.opt 2007-01-09 15:01:52.000000000 +0000 @@ -20,27 +20,27 @@ ; 02110-1301, USA. m5200 -Target RejectNegative Mask(5200) +Target RejectNegative Generate code for a 520X m5206e -Target RejectNegative Mask(CF_HWDIV) +Target RejectNegative Generate code for a 5206e m528x -Target RejectNegative Mask(528x) +Target RejectNegative Generate code for a 528x m5307 -Target RejectNegative Mask(CFV3) +Target RejectNegative Generate code for a 5307 m5407 -Target RejectNegative Mask(CFV4) +Target RejectNegative Generate code for a 5407 mcfv4e -Target RejectNegative Mask(CFV4E) +Target RejectNegative Generate code for a ColdFire v4e m68000 @@ -48,27 +48,27 @@ Target RejectNegative Generate code for a 68000 m68010 -Target RejectNegative Mask(68010) +Target RejectNegative Generate code for a 68010 m68020 -Target RejectNegative Mask(68020) +Target RejectNegative Generate code for a 68020 m68020-40 -Target RejectNegative Mask(68040) +Target RejectNegative Generate code for a 68040, without any new instructions m68020-60 -Target RejectNegative Mask(68060) +Target RejectNegative Generate code for a 68060, without any new instructions m68030 -Target RejectNegative Mask(68030) +Target RejectNegative Generate code for a 68030 m68040 -Target RejectNegative Mask(68040_ONLY) +Target RejectNegative Generate code for a 68040 m68060 @@ -89,13 +89,17 @@ Target Generate code for a 68851 m68881 -Target RejectNegative Mask(68881) +Target RejectNegative Mask(HARD_FLOAT) Generate code that uses 68881 floating-point instructions malign-int Target Report Mask(ALIGN_INT) Align variables on a 32-bit boundary +march= +Target RejectNegative Joined +Specify the name of the target architecture + mbitfield Target Report RejectNegative Mask(BITFIELD) Use the bit-field instructions @@ -108,10 +112,22 @@ mc68020 Target RejectNegative Generate code for a 68020 +mcpu= +Target RejectNegative Joined +Specify the target CPU + mcpu32 Target RejectNegative Generate code for a cpu32 +mdiv +Target Report Mask(CF_HWDIV) +Use hardware division instructions on ColdFire + +mhard-float +Target RejectNegative Mask(HARD_FLOAT) MaskExists +Generate code which uses hardware floating point instructions + mid-shared-library Target Report Mask(ID_SHARED_LIBRARY) Enable ID based shared library @@ -149,9 +165,13 @@ Target Report RejectNegative Mask(SHORT) Consider type 'int' to be 16 bits wide msoft-float -Target RejectNegative InverseMask(68881) +Target RejectNegative InverseMask(HARD_FLOAT) Generate code with library calls for floating point mstrict-align Target Report Mask(STRICT_ALIGNMENT) Do not use unaligned memory references + +mtune= +Target RejectNegative Joined +Tune for the specified target CPU or architecture Index: gcc/config/m68k/m68k-devices.def =================================================================== --- /dev/null 2007-01-09 03:39:34.548096750 +0000 +++ gcc/config/m68k/m68k-devices.def 2007-01-09 15:01:52.000000000 +0000 @@ -0,0 +1,144 @@ +/* m68k device names -*- C -*- + Copyright (C) 2005, 2006 Free Software Foundation, Inc. + Written by CodeSourcery + + This file is part of GCC. + + GCC is free software; you can redistribute it and/or modify it + under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 2, or (at your option) + any later version. + + GCC is distributed in the hope that it will be useful, but + WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + General Public License for more details. + + You should have received a copy of the GNU General Public License + along with GCC; see the file COPYING. If not, write to the Free + Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA + 02110-1301, USA. */ + +/* This file lists each target device that we support. It is used by + both C code and build scripts. + + Following Freescale's lead, we group devices into families that share + the same core and extension units. Devices in these families differ + only in the set of peripherals they provide. We pick one device to + act as the representative of each family. + + We further group device families into multilibs, again picking one + family (and its representative device) to represent each multilib. + + Devices are declared using the construct: + + M68K_DEVICE (NAME, ENUM_VALUE, FAMILY, MULTILIB, MICROARCH, ISA, FLAGS) + + where the arguments are as follows: + + NAME + The name of the device as a string. This string acts as the + device's -mcpu argument and is guaranteed to be unique. + + ENUM_VALUE + The associated value in the target_device enumeration. + This value is also guaranteed to be unique. + + FAMILY + The NAME field of the family's representative device. + + MULTILIB + The NAME field of the multilib's representative device. + + MICROARCH + The class of core used by devices in this family. The field + is a uarch enumeration value without the leading "u". + + ISA + The ISA implemented by this family. The field is + an m68k_isa enumeration value. + + FLAGS + The FL_* flags that apply to this family, excluding FL_FOR_isa_*. + See m68k.h for the full list. + + There is a bit of duplication between devices in the same family, + but this approach makes scripting easier. We keep each entry on + a single line for the same reason. */ + +/* 680x0 series processors. */ +M68K_DEVICE ("68000", m68000, "68000", "68000", 68000, isa_00, 0) +M68K_DEVICE ("68010", m68010, "68010", "68000", 68010, isa_10, 0) +M68K_DEVICE ("68020", m68020, "68020", "68020", 68020, isa_20, FL_MMU) +M68K_DEVICE ("68030", m68030, "68030", "68020", 68030, isa_20, FL_MMU) +M68K_DEVICE ("68040", m68040, "68040", "68040", 68040, isa_40, FL_MMU) +M68K_DEVICE ("68060", m68060, "68060", "68060", 68060, isa_40, FL_MMU) +M68K_DEVICE ("68302", m68302, "68302", "68000", 68000, isa_00, FL_MMU) +M68K_DEVICE ("68332", m68332, "68332", "cpu32", cpu32, isa_cpu32, FL_MMU) +M68K_DEVICE ("cpu32", cpu32, "cpu32", "cpu32", cpu32, isa_cpu32, FL_MMU) + +/* ColdFire CFV2 processors. */ +M68K_DEVICE ("5202", mcf5202, "5206", "5206", cfv2, isa_a, 0) +M68K_DEVICE ("5204", mcf5204, "5206", "5206", cfv2, isa_a, 0) +M68K_DEVICE ("5206", mcf5206, "5206", "5206", cfv2, isa_a, 0) +M68K_DEVICE ("5206e", mcf5206e, "5206e", "5206e", cfv2, isa_a, FL_CF_HWDIV | FL_CF_MAC) +M68K_DEVICE ("5207", mcf5207, "5208", "5208", cfv2, isa_aplus, FL_CF_HWDIV | FL_CF_EMAC) +M68K_DEVICE ("5208", mcf5208, "5208", "5208", cfv2, isa_aplus, FL_CF_HWDIV | FL_CF_EMAC) +M68K_DEVICE ("5210a", mcf5210a, "5211a", "5213", cfv2, isa_aplus, FL_CF_HWDIV | FL_CF_MAC) +M68K_DEVICE ("5211a", mcf5211a, "5211a", "5213", cfv2, isa_aplus, FL_CF_HWDIV | FL_CF_MAC) +M68K_DEVICE ("5211", mcf5211, "5213", "5213", cfv2, isa_aplus, FL_CF_HWDIV | FL_CF_MAC) +M68K_DEVICE ("5212", mcf5212, "5213", "5213", cfv2, isa_aplus, FL_CF_HWDIV | FL_CF_MAC) +M68K_DEVICE ("5213", mcf5213, "5213", "5213", cfv2, isa_aplus, FL_CF_HWDIV | FL_CF_MAC) +M68K_DEVICE ("5214", mcf5214, "5216", "5208", cfv2, isa_aplus, FL_CF_HWDIV | FL_CF_EMAC) +M68K_DEVICE ("5216", mcf5216, "5216", "5208", cfv2, isa_aplus, FL_CF_HWDIV | FL_CF_EMAC) +M68K_DEVICE ("52230", mcf52230, "52235", "5208", cfv2, isa_aplus, FL_CF_HWDIV | FL_CF_EMAC) +M68K_DEVICE ("52231", mcf52231, "52235", "5208", cfv2, isa_aplus, FL_CF_HWDIV | FL_CF_EMAC) +M68K_DEVICE ("52232", mcf52232, "52235", "5208", cfv2, isa_aplus, FL_CF_HWDIV | FL_CF_EMAC) +M68K_DEVICE ("52233", mcf52233, "52235", "5208", cfv2, isa_aplus, FL_CF_HWDIV | FL_CF_EMAC) +M68K_DEVICE ("52234", mcf52234, "52235", "5208", cfv2, isa_aplus, FL_CF_HWDIV | FL_CF_EMAC) +M68K_DEVICE ("52235", mcf52235, "52235", "5208", cfv2, isa_aplus, FL_CF_HWDIV | FL_CF_EMAC) +M68K_DEVICE ("5224", mcf5224, "5225", "5213", cfv2, isa_aplus, FL_CF_HWDIV | FL_CF_MAC) +M68K_DEVICE ("5225", mcf5225, "5225", "5213", cfv2, isa_aplus, FL_CF_HWDIV | FL_CF_MAC) +M68K_DEVICE ("5232", mcf5232, "5235", "5208", cfv2, isa_aplus, FL_CF_HWDIV | FL_CF_EMAC) +M68K_DEVICE ("5233", mcf5233, "5235", "5208", cfv2, isa_aplus, FL_CF_HWDIV | FL_CF_EMAC) +M68K_DEVICE ("5234", mcf5234, "5235", "5208", cfv2, isa_aplus, FL_CF_HWDIV | FL_CF_EMAC) +M68K_DEVICE ("5235", mcf5235, "5235", "5208", cfv2, isa_aplus, FL_CF_HWDIV | FL_CF_EMAC) +M68K_DEVICE ("523x", mcf523x, "5235", "5208", cfv2, isa_aplus, FL_CF_HWDIV | FL_CF_EMAC) +M68K_DEVICE ("5249", mcf5249, "5249", "5249", cfv2, isa_a, FL_CF_HWDIV | FL_CF_EMAC) +M68K_DEVICE ("5250", mcf5250, "5250", "5249", cfv2, isa_a, FL_CF_HWDIV | FL_CF_EMAC) +M68K_DEVICE ("5270", mcf5270, "5271", "5208", cfv2, isa_aplus, FL_CF_HWDIV | FL_CF_EMAC) +M68K_DEVICE ("5271", mcf5271, "5271", "5208", cfv2, isa_aplus, FL_CF_HWDIV) +M68K_DEVICE ("5272", mcf5272, "5272", "5206e", cfv2, isa_a, FL_CF_HWDIV | FL_CF_MAC) +M68K_DEVICE ("5274", mcf5274, "5275", "5208", cfv2, isa_aplus, FL_CF_HWDIV | FL_CF_EMAC) +M68K_DEVICE ("5275", mcf5275, "5275", "5208", cfv2, isa_aplus, FL_CF_HWDIV | FL_CF_EMAC) +M68K_DEVICE ("5280", mcf5280, "5282", "5208", cfv2, isa_aplus, FL_CF_HWDIV | FL_CF_EMAC) +M68K_DEVICE ("5281", mcf5281, "5282", "5208", cfv2, isa_aplus, FL_CF_HWDIV | FL_CF_EMAC) +M68K_DEVICE ("5282", mcf5282, "5282", "5208", cfv2, isa_aplus, FL_CF_HWDIV | FL_CF_EMAC) +M68K_DEVICE ("528x", mcf528x, "5282", "5208", cfv2, isa_aplus, FL_CF_HWDIV | FL_CF_EMAC) + +/* CFV3 processors. */ +M68K_DEVICE ("5307", mcf5307, "5307", "5307", cfv3, isa_a, FL_CF_HWDIV | FL_CF_MAC) +M68K_DEVICE ("5327", mcf5327, "5329", "5329", cfv3, isa_aplus, FL_CF_HWDIV | FL_CF_EMAC) +M68K_DEVICE ("5328", mcf5328, "5329", "5329", cfv3, isa_aplus, FL_CF_HWDIV | FL_CF_EMAC) +M68K_DEVICE ("5329", mcf5329, "5329", "5329", cfv3, isa_aplus, FL_CF_HWDIV | FL_CF_EMAC) +M68K_DEVICE ("532x", mcf532x, "5329", "5329", cfv3, isa_aplus, FL_CF_HWDIV | FL_CF_EMAC) +M68K_DEVICE ("5372", mcf5372, "5373", "5329", cfv3, isa_aplus, FL_CF_HWDIV | FL_CF_EMAC) +M68K_DEVICE ("5373", mcf5373, "5373", "5329", cfv3, isa_aplus, FL_CF_HWDIV | FL_CF_EMAC) +M68K_DEVICE ("537x", mcf537x, "5373", "5329", cfv3, isa_aplus, FL_CF_HWDIV | FL_CF_EMAC) + +/* CFV4/CFV4e processors. */ +M68K_DEVICE ("5407", mcf5407, "5407", "5407", cfv4, isa_b, FL_CF_MAC) +M68K_DEVICE ("5470", mcf5470, "5475", "5475", cfv4e, isa_b, FL_CF_USP | FL_CF_EMAC | FL_CF_FPU | FL_MMU) +M68K_DEVICE ("5471", mcf5471, "5475", "5475", cfv4e, isa_b, FL_CF_USP | FL_CF_EMAC | FL_CF_FPU | FL_MMU) +M68K_DEVICE ("5472", mcf5472, "5475", "5475", cfv4e, isa_b, FL_CF_USP | FL_CF_EMAC | FL_CF_FPU | FL_MMU) +M68K_DEVICE ("5473", mcf5473, "5475", "5475", cfv4e, isa_b, FL_CF_USP | FL_CF_EMAC | FL_CF_FPU | FL_MMU) +M68K_DEVICE ("5474", mcf5474, "5475", "5475", cfv4e, isa_b, FL_CF_USP | FL_CF_EMAC | FL_CF_FPU | FL_MMU) +M68K_DEVICE ("5475", mcf5475, "5475", "5475", cfv4e, isa_b, FL_CF_USP | FL_CF_EMAC | FL_CF_FPU | FL_MMU) +M68K_DEVICE ("547x", mcf547x, "5475", "5475", cfv4e, isa_b, FL_CF_USP | FL_CF_EMAC | FL_CF_FPU | FL_MMU) +M68K_DEVICE ("5480", mcf5480, "5485", "5475", cfv4e, isa_b, FL_CF_USP | FL_CF_EMAC | FL_CF_FPU | FL_MMU) +M68K_DEVICE ("5481", mcf5481, "5485", "5475", cfv4e, isa_b, FL_CF_USP | FL_CF_EMAC | FL_CF_FPU | FL_MMU) +M68K_DEVICE ("5482", mcf5482, "5485", "5475", cfv4e, isa_b, FL_CF_USP | FL_CF_EMAC | FL_CF_FPU | FL_MMU) +M68K_DEVICE ("5483", mcf5483, "5485", "5475", cfv4e, isa_b, FL_CF_USP | FL_CF_EMAC | FL_CF_FPU | FL_MMU) +M68K_DEVICE ("5484", mcf5484, "5485", "5475", cfv4e, isa_b, FL_CF_USP | FL_CF_EMAC | FL_CF_FPU | FL_MMU) +M68K_DEVICE ("5485", mcf5485, "5485", "5475", cfv4e, isa_b, FL_CF_USP | FL_CF_EMAC | FL_CF_FPU | FL_MMU) +M68K_DEVICE ("548x", mcf548x, "5485", "5475", cfv4e, isa_b, FL_CF_USP | FL_CF_EMAC | FL_CF_FPU | FL_MMU) ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 10/63] Rename TARGET_68040_ONLY to TARGET_68040 2007-01-10 10:54 ` [ColdFire 9/63] Add -mcpu, -march, -mtune, and related options Richard Sandiford @ 2007-01-10 10:55 ` Richard Sandiford 2007-01-10 10:57 ` [ColdFire 11/63] Treat mc680x0 macros as tuning-dependent macros Richard Sandiford 2007-01-10 18:27 ` [ColdFire 10/63] Rename TARGET_68040_ONLY to TARGET_68040 Jeffrey Law 2007-01-10 18:22 ` [ColdFire 9/63] Add -mcpu, -march, -mtune, and related options Jeffrey Law ` (2 subsequent siblings) 3 siblings, 2 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 10:55 UTC (permalink / raw) To: gcc-patches At this point in the series, we've got rid of the architecture MASK_*s and added TUNE_* macros. TARGET_68040_ONLY can now be called TARGET_68040, for consistency with the other ISA macros. Richard gcc/ 200x-xx-xx Julian Brown <julian@codesourcery.com> * config/m68k/m68k.h: Use TARGET_68040 instead of TARGET_68040_ONLY. (TARGET_68040_ONLY): Rename to... (TARGET_68040): ...this. * config/m68k/m68k.c: Use TARGET_68040 instead of TARGET_68040_ONLY. * config/m68k/m68k.md: Likewise. Index: gcc/config/m68k/m68k.h =================================================================== --- gcc/config/m68k/m68k.h 2007-01-09 15:01:52.000000000 +0000 +++ gcc/config/m68k/m68k.h 2007-01-09 15:01:53.000000000 +0000 @@ -67,7 +67,7 @@ #define TARGET_CPU_CPP_BUILTINS() \ { \ builtin_define ("__m68k__"); \ builtin_define_std ("mc68000"); \ - if (TARGET_68040_ONLY) \ + if (TARGET_68040) \ { \ if (TUNE_68060) \ builtin_define_std ("mc68060"); \ @@ -182,7 +182,7 @@ #define FL_MMU 0 /* Used by mult #define TARGET_68010 ((m68k_cpu_flags & FL_ISA_68010) != 0) #define TARGET_68020 ((m68k_cpu_flags & FL_ISA_68020) != 0) -#define TARGET_68040_ONLY ((m68k_cpu_flags & FL_ISA_68040) != 0) +#define TARGET_68040 ((m68k_cpu_flags & FL_ISA_68040) != 0) #define TARGET_COLDFIRE ((m68k_cpu_flags & FL_COLDFIRE) != 0) #define TARGET_COLDFIRE_FPU (m68k_fpu == FPUTYPE_COLDFIRE) #define TARGET_68881 (m68k_fpu == FPUTYPE_68881) @@ -220,7 +220,7 @@ #define LONG_DOUBLE_TYPE_SIZE 80 /* Set the value of FLT_EVAL_METHOD in float.h. When using 68040 fp instructions, we get proper intermediate rounding, otherwise we get extended precision results. */ -#define TARGET_FLT_EVAL_METHOD ((TARGET_68040_ONLY || ! TARGET_68881) ? 0 : 2) +#define TARGET_FLT_EVAL_METHOD ((TARGET_68040 || ! TARGET_68881) ? 0 : 2) #define BITS_BIG_ENDIAN 1 #define BYTES_BIG_ENDIAN 1 Index: gcc/config/m68k/m68k.c =================================================================== --- gcc/config/m68k/m68k.c 2007-01-09 15:01:52.000000000 +0000 +++ gcc/config/m68k/m68k.c 2007-01-09 15:01:53.000000000 +0000 @@ -3086,12 +3086,12 @@ print_operand (FILE *file, rtx op, int l asm_fprintf (file, "%Rfpcr"); else if (letter == '$') { - if (TARGET_68040_ONLY) + if (TARGET_68040) fprintf (file, "s"); } else if (letter == '&') { - if (TARGET_68040_ONLY) + if (TARGET_68040) fprintf (file, "d"); } else if (letter == '/') Index: gcc/config/m68k/m68k.md =================================================================== --- gcc/config/m68k/m68k.md 2007-01-09 15:01:49.000000000 +0000 +++ gcc/config/m68k/m68k.md 2007-01-09 15:01:53.000000000 +0000 @@ -1659,7 +1659,7 @@ (define_insn "" [(set (match_operand:SF 0 "nonimmediate_operand" "=f") (float_truncate:SF (match_operand:DF 1 "general_operand" "fmG")))] - "TARGET_68881 && TARGET_68040_ONLY" + "TARGET_68881 && TARGET_68040" { if (FP_REG_P (operands[1])) return "f%$move%.x %1,%0"; @@ -2834,7 +2834,7 @@ (define_insn "mul<mode>3_floatsi_68881" (match_operand:FP 1 "general_operand" "0")))] "TARGET_68881" { - return TARGET_68040_ONLY + return TARGET_68040 ? "f<FP:round>mul%.l %2,%0" : "f<FP:round_mul>mul%.l %2,%0"; }) @@ -2845,7 +2845,7 @@ (define_insn "mul<mode>3_floathi_68881" (match_operand:FP 1 "general_operand" "0")))] "TARGET_68881" { - return TARGET_68040_ONLY + return TARGET_68040 ? "f<FP:round>mul%.w %2,%0" : "f<FP:round_mul>mul%.w %2,%0"; }) @@ -2856,7 +2856,7 @@ (define_insn "mul<mode>3_floatqi_68881" (match_operand:FP 1 "general_operand" "0")))] "TARGET_68881" { - return TARGET_68040_ONLY + return TARGET_68040 ? "f<FP:round>mul%.b %2,%0" : "f<FP:round_mul>mul%.b %2,%0"; }) @@ -2886,10 +2886,10 @@ (define_insn "mulsf_68881" "TARGET_68881" { if (FP_REG_P (operands[2])) - return (TARGET_68040_ONLY + return (TARGET_68040 ? "fsmul%.x %2,%0" : "fsglmul%.x %2,%0"); - return (TARGET_68040_ONLY + return (TARGET_68040 ? "fsmul%.s %f2,%0" : "fsglmul%.s %f2,%0"); }) @@ -2929,7 +2929,7 @@ (define_insn "div<mode>3_floatsi_68881" (float:FP (match_operand:SI 2 "general_operand" "dmi"))))] "TARGET_68881" { - return TARGET_68040_ONLY + return TARGET_68040 ? "f<FP:round>div%.l %2,%0" : "f<FP:round_mul>div%.l %2,%0"; }) @@ -2940,7 +2940,7 @@ (define_insn "div<mode>3_floathi_68881" (float:FP (match_operand:HI 2 "general_operand" "dmn"))))] "TARGET_68881" { - return TARGET_68040_ONLY + return TARGET_68040 ? "f<FP:round>div%.w %2,%0" : "f<FP:round_mul>div%.w %2,%0"; }) @@ -2951,7 +2951,7 @@ (define_insn "div<mode>3_floatqi_68881" (float:FP (match_operand:QI 2 "general_operand" "dmn"))))] "TARGET_68881" { - return TARGET_68040_ONLY + return TARGET_68040 ? "f<FP:round>div%.b %2,%0" : "f<FP:round_mul>div%.b %2,%0"; }) @@ -2963,10 +2963,10 @@ (define_insn "div<mode>3_68881" "TARGET_68881" { if (FP_REG_P (operands[2])) - return (TARGET_68040_ONLY + return (TARGET_68040 ? "f<FP:round>div%.x %2,%0" : "f<FP:round_mul>div%.x %2,%0"); - return (TARGET_68040_ONLY + return (TARGET_68040 ? "f<FP:round>div%.<FP:prec> %f2,%0" : "f<FP:round_mul>div%.<FP:prec> %f2,%0"); }) ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 11/63] Treat mc680x0 macros as tuning-dependent macros 2007-01-10 10:55 ` [ColdFire 10/63] Rename TARGET_68040_ONLY to TARGET_68040 Richard Sandiford @ 2007-01-10 10:57 ` Richard Sandiford 2007-01-10 10:58 ` [ColdFire 12/63] Add new predefined macros Richard Sandiford 2007-01-10 18:28 ` [ColdFire 11/63] Treat mc680x0 macros as tuning-dependent macros Jeffrey Law 2007-01-10 18:27 ` [ColdFire 10/63] Rename TARGET_68040_ONLY to TARGET_68040 Jeffrey Law 1 sibling, 2 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 10:57 UTC (permalink / raw) To: gcc-patches The mc680[12346]0 macros are effectively tuning macros. E.g. -m68020-40 sets mc68020, mc68030 and mc68040, even though it only generates mc68020 instructions. This patch makes that more explicit by setting the macros in an m68k_tune switch statement. The next patch will add ColdFire macros to it. Richard gcc/ * config/m68k/m68k.h (TARGET_CPU_CPP_BUILTINS): Treat all mc68* macros besides mc68000 as tuning macros. Use a switch statement to set them and mcpu32. Index: gcc/config/m68k/m68k.h =================================================================== *** gcc/config/m68k/m68k.h 2007-01-09 15:01:53.000000000 +0000 --- gcc/config/m68k/m68k.h 2007-01-09 15:01:54.000000000 +0000 *************** #define TARGET_CPU_CPP_BUILTINS() \ *** 67,105 **** { \ builtin_define ("__m68k__"); \ builtin_define_std ("mc68000"); \ ! if (TARGET_68040) \ ! { \ ! if (TUNE_68060) \ ! builtin_define_std ("mc68060"); \ ! else \ ! builtin_define_std ("mc68040"); \ ! } \ ! else if (TUNE_68060) /* -m68020-60 */ \ { \ builtin_define_std ("mc68060"); \ builtin_define_std ("mc68040"); \ builtin_define_std ("mc68030"); \ builtin_define_std ("mc68020"); \ ! } \ ! else if (TUNE_68040) /* -m68020-40 */ \ ! { \ ! builtin_define_std ("mc68040"); \ ! builtin_define_std ("mc68030"); \ builtin_define_std ("mc68020"); \ } \ ! else if (TUNE_68030) \ ! builtin_define_std ("mc68030"); \ ! else if (TARGET_68020) \ ! builtin_define_std ("mc68020"); \ ! else if (TUNE_68010) \ ! builtin_define_std ("mc68010"); \ if (TARGET_68881) \ builtin_define ("__HAVE_68881__"); \ ! if (TUNE_CPU32) \ ! { \ ! builtin_define_std ("mc68332"); \ ! builtin_define_std ("mcpu32"); \ ! } \ if (TARGET_COLDFIRE) \ { \ builtin_define ("__mcoldfire__"); \ --- 67,119 ---- { \ builtin_define ("__m68k__"); \ builtin_define_std ("mc68000"); \ ! /* The other mc680x0 macros have traditionally been derived \ ! from the tuning setting. For example, -m68020-60 defines \ ! m68060, even though it generates pure 68020 code. */ \ ! switch (m68k_tune) \ { \ + case u68010: \ + builtin_define_std ("mc68010"); \ + break; \ + \ + case u68020: \ + builtin_define_std ("mc68020"); \ + break; \ + \ + case u68030: \ + builtin_define_std ("mc68030"); \ + break; \ + \ + case u68040: \ + builtin_define_std ("mc68040"); \ + break; \ + \ + case u68060: \ + builtin_define_std ("mc68060"); \ + break; \ + \ + case u68020_60: \ builtin_define_std ("mc68060"); \ + /* Fall through. */ \ + case u68020_40: \ builtin_define_std ("mc68040"); \ builtin_define_std ("mc68030"); \ builtin_define_std ("mc68020"); \ ! break; \ ! \ ! case ucpu32: \ ! builtin_define_std ("mc68332"); \ ! builtin_define_std ("mcpu32"); \ builtin_define_std ("mc68020"); \ + break; \ + \ + default: \ + break; \ } \ ! \ if (TARGET_68881) \ builtin_define ("__HAVE_68881__"); \ ! \ if (TARGET_COLDFIRE) \ { \ builtin_define ("__mcoldfire__"); \ ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 12/63] Add new predefined macros 2007-01-10 10:57 ` [ColdFire 11/63] Treat mc680x0 macros as tuning-dependent macros Richard Sandiford @ 2007-01-10 10:58 ` Richard Sandiford 2007-01-10 11:00 ` [ColdFire 13/63] Remove some RejectNegatives Richard Sandiford 2007-01-10 18:31 ` [ColdFire 12/63] Add new predefined macros Jeffrey Law 2007-01-10 18:28 ` [ColdFire 11/63] Treat mc680x0 macros as tuning-dependent macros Jeffrey Law 1 sibling, 2 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 10:58 UTC (permalink / raw) To: gcc-patches This patch adds some new cpp macros. Specifically: - it adds __mcfv[2345]__ macros, to go alongside the existing __mcfv4e__. - it defines __mcffpu__ when the ColdFire FPU is enabled - it defines __mcf_cpu_CPU and __mcf_family_FAMILY when a ColdFire CPU is selected. (These macros are used in the libgloss crt code.) The patch also documents some existing macros in invoke.texi. Richard gcc/ 200x-xx-xx Nathan Sidwell <nathan@codesourcery.com> Richard Sandiford <richard@codesourcery.com> * doc/invoke.texi: Document the macros that are defined by m68k's -mtune and -mhard-float options. * config/m68k/m68k-protos.h (m68k_cpp_cpu_ident) Declare. (m68k_cpp_cpu_family): Likewise. * config/m68k/m68k.h (TARGET_CPU_CPP_BUILTINS): Add a full set of __ucfv*__ macros. Define __mcffpu__ if generating code for ColdFire FPUs. Define __mcf_cpu_* and __mcf_family_* macros. * config/m68k/m68k.c (m68k_cpp_cpu_ident): New function. (m68k_cpp_cpu_family): Likewise. Index: gcc/doc/invoke.texi =================================================================== --- gcc/doc/invoke.texi 2007-01-09 15:01:52.000000000 +0000 +++ gcc/doc/invoke.texi 2007-01-09 15:01:54.000000000 +0000 @@ -10284,6 +10284,10 @@ below, which also classifies the CPUs in @var{arch} is compatible with @var{cpu}. Other combinations of @option{-mcpu} and @option{-march} are rejected. +gcc defines the macro @samp{__mcf_cpu_@var{cpu}} when ColdFire target +@var{cpu} is selected. It also defines @samp{__mcf_family_@var{family}}, +where the value of @var{family} is given by the table above. + @item -mtune=@var{tune} @opindex mtune Tune the code for a particular microarchitecture, within the @@ -10299,6 +10303,17 @@ to run relatively well on 68020, 68030 a as well. These two options select the same tuning decisions as @option{-m68020-40} and @option{-m68020-60} respectively. +gcc defines the macros @samp{__mc@var{arch}} and @samp{__mc@var{arch}__} +when tuning for 680x0 architecture @var{arch}. It also defines +@samp{mc@var{arch}} unless either @option{-ansi} or a non-GNU @option{-std} +option is used. If gcc is tuning for a range of architectures, +as selected by @option{-mtune=68020-40} or @option{-mtune=68020-60}, +it defines the macros for every architecture in the range. + +gcc also defines the macro @samp{__m@var{uarch}__} when tuning for +ColdFire microarchitecture @var{uarch}, where @var{uarch} is one +of the arguments given above. + @item -m68000 @itemx -mc68000 @opindex m68000 @@ -10421,7 +10436,9 @@ The option is equivalent to @option{-mar @opindex mhard-float @opindex m68881 Generate floating-point instructions. This is the default for 68020 -and above, and for ColdFire devices that have an FPU. +and above, and for ColdFire devices that have an FPU. It defines the +macro @samp{__HAVE_68881__} on M680x0 targets and @samp{__mcffpu__} +on ColdFire targets. @item -msoft-float @opindex msoft-float Index: gcc/config/m68k/m68k-protos.h =================================================================== --- gcc/config/m68k/m68k-protos.h 2007-01-09 15:01:42.000000000 +0000 +++ gcc/config/m68k/m68k-protos.h 2007-01-09 15:01:54.000000000 +0000 @@ -61,5 +61,7 @@ extern bool m68k_regno_mode_ok (int, enu extern int flags_in_68881 (void); extern bool use_return_insn (void); extern void override_options (void); +extern const char *m68k_cpp_cpu_ident (const char *); +extern const char *m68k_cpp_cpu_family (const char *); extern void init_68881_table (void); extern int m68k_hard_regno_rename_ok(unsigned int, unsigned int); Index: gcc/config/m68k/m68k.h =================================================================== --- gcc/config/m68k/m68k.h 2007-01-09 15:01:54.000000000 +0000 +++ gcc/config/m68k/m68k.h 2007-01-09 15:01:54.000000000 +0000 @@ -107,6 +107,26 @@ #define TARGET_CPU_CPP_BUILTINS() \ builtin_define_std ("mc68020"); \ break; \ \ + case ucfv2: \ + builtin_define ("__mcfv2__"); \ + break; \ + \ + case ucfv3: \ + builtin_define ("__mcfv3__"); \ + break; \ + \ + case ucfv4: \ + builtin_define ("__mcfv4__"); \ + break; \ + \ + case ucfv4e: \ + builtin_define ("__mcfv4e__"); \ + break; \ + \ + case ucfv5: \ + builtin_define ("__mcfv5__"); \ + break; \ + \ default: \ break; \ } \ @@ -116,7 +136,16 @@ #define TARGET_CPU_CPP_BUILTINS() \ \ if (TARGET_COLDFIRE) \ { \ + const char *tmp; \ + \ + tmp = m68k_cpp_cpu_ident ("cf"); \ + if (tmp) \ + builtin_define (tmp); \ + tmp = m68k_cpp_cpu_family ("cf"); \ + if (tmp) \ + builtin_define (tmp); \ builtin_define ("__mcoldfire__"); \ + \ if (TARGET_ISAC) \ builtin_define ("__mcfisac__"); \ else if (TARGET_ISAB) \ @@ -152,10 +181,11 @@ #define TARGET_CPU_CPP_BUILTINS() \ break; \ } \ } \ - if (m68k_tune == ucfv4e) \ - builtin_define ("__mcfv4e__"); \ } \ \ + if (TARGET_COLDFIRE_FPU) \ + builtin_define ("__mcffpu__"); \ + \ if (TARGET_CF_HWDIV) \ builtin_define ("__mcfhwdiv__"); \ \ Index: gcc/config/m68k/m68k.c =================================================================== --- gcc/config/m68k/m68k.c 2007-01-09 15:01:53.000000000 +0000 +++ gcc/config/m68k/m68k.c 2007-01-09 15:01:54.000000000 +0000 @@ -540,6 +540,30 @@ override_options (void) SUBTARGET_OVERRIDE_OPTIONS; } + +/* Generate a macro of the form __mPREFIX_cpu_NAME, where PREFIX is the + given argument and NAME is the argument passed to -mcpu. Return NULL + if -mcpu was not passed. */ + +const char * +m68k_cpp_cpu_ident (const char *prefix) +{ + if (!m68k_cpu_entry) + return NULL; + return concat ("__m", prefix, "_cpu_", m68k_cpu_entry->name, NULL); +} + +/* Generate a macro of the form __mPREFIX_family_NAME, where PREFIX is the + given argument and NAME is the name of the representative device for + the -mcpu argument's family. Return NULL if -mcpu was not passed. */ + +const char * +m68k_cpp_cpu_family (const char *prefix) +{ + if (!m68k_cpu_entry) + return NULL; + return concat ("__m", prefix, "_family_", m68k_cpu_entry->family, NULL); +} \f /* Return nonzero if FUNC is an interrupt function as specified by the "interrupt_handler" attribute. */ ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 13/63] Remove some RejectNegatives 2007-01-10 10:58 ` [ColdFire 12/63] Add new predefined macros Richard Sandiford @ 2007-01-10 11:00 ` Richard Sandiford 2007-01-10 11:02 ` [ColdFire 14/63] Make "long double" the same as "double" on ColdFire Richard Sandiford 2007-01-10 18:32 ` [ColdFire 13/63] Remove some RejectNegatives Jeffrey Law 2007-01-10 18:31 ` [ColdFire 12/63] Add new predefined macros Jeffrey Law 1 sibling, 2 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 11:00 UTC (permalink / raw) To: gcc-patches Some of the boolean m68k options have no negative counterpart. There seems to be no specific reason for this, as the negatives would work, so this patch adds them. -mno-bitfield is now a (more canonical) synonym for -mnobitfield. (I suppose that before the .opt transition, it was more effort to add boolean options with negative counterparts, whereas the opposite is now true. As before, I'd tried to preserve existing practice when converting the m68k port.) The patch also resorts m68k.opt into alphabetical order. Richard gcc/ 200x-xx-xx Nathan Sidwell <nathan@codesourcery.com> Richard Sandiford <richard@codesourcery.com> * doc/invoke.texi: Document -mno-bitfield, -mno-rtd and -mno-short. * config/m68k/m68k.opt: Resort options. (mbitfield, mrtd, mshort): Remove RejectNegative properties. Index: gcc/doc/invoke.texi =================================================================== --- gcc/doc/invoke.texi 2007-01-10 08:33:02.000000000 +0000 +++ gcc/doc/invoke.texi 2007-01-10 10:18:48.000000000 +0000 @@ -583,9 +583,9 @@ Objective-C and Objective-C++ Dialects}. @gccoptlist{-march=@var{arch} -mcpu=@var{cpu} -mtune=@var{tune} -m68000 -m68020 -m68020-40 -m68020-60 -m68030 -m68040 @gol -m68060 -mcpu32 -m5200 -m5206e -m528x -m5307 -m5407 @gol --mcfv4e -mbitfield -mc68000 -mc68020 @gol --mnobitfield -mrtd -mdiv -mno-div -mshort @gol --mhard-float -m68881 -msoft-float -mpcrel @gol +-mcfv4e -mbitfield -mno-bitfield -mc68000 -mc68020 @gol +-mnobitfield -mrtd -mno-rtd -mdiv -mno-div -mshort @gol +-mno-short -mhard-float -m68881 -msoft-float -mpcrel @gol -malign-int -mstrict-align -msep-data -mno-sep-data @gol -mshared-library-id=n -mid-shared-library -mno-id-shared-library} @@ -10510,8 +10510,14 @@ Consider type @code{int} to be 16 bits w Additionally, parameters passed on the stack are also aligned to a 16-bit boundary even on targets whose API mandates promotion to 32-bit. +@item -mno-short +@opindex -mno-short +Do not consider type @code{int} to be 16 bits wide. This is the default. + @item -mnobitfield +@itemx -mno-bitfield @opindex mnobitfield +@opindex mno-bitfield Do not use the bit-field instructions. The @option{-m68000}, @option{-mcpu32} and @option{-m5200} options imply @w{@option{-mnobitfield}}. @@ -10545,6 +10551,11 @@ harmlessly ignored.) The @code{rtd} instruction is supported by the 68010, 68020, 68030, 68040, 68060 and CPU32 processors, but not by the 68000 or 5200. +@item -mno-rtd +@opindex mno-rtd +Do not use the calling conventions selected by @option{-mrtd}. +This is the default. + @item -malign-int @itemx -mno-align-int @opindex malign-int Index: gcc/config/m68k/m68k.opt =================================================================== --- gcc/config/m68k/m68k.opt 2007-01-10 08:33:02.000000000 +0000 +++ gcc/config/m68k/m68k.opt 2007-01-10 08:33:02.000000000 +0000 @@ -39,10 +39,6 @@ m5407 Target RejectNegative Generate code for a 5407 -mcfv4e -Target RejectNegative -Generate code for a ColdFire v4e - m68000 Target RejectNegative Generate code for a 68000 @@ -101,7 +97,7 @@ Target RejectNegative Joined Specify the name of the target architecture mbitfield -Target Report RejectNegative Mask(BITFIELD) +Target Report Mask(BITFIELD) Use the bit-field instructions mc68000 @@ -112,6 +108,10 @@ mc68020 Target RejectNegative Generate code for a 68020 +mcfv4e +Target RejectNegative +Generate code for a ColdFire v4e + mcpu= Target RejectNegative Joined Specify the target CPU @@ -149,7 +149,7 @@ Target Report Mask(PCREL) Generate pc-relative code mrtd -Target Report RejectNegative Mask(RTD) +Target Report Mask(RTD) Use different calling convention using 'rtd' msep-data @@ -161,7 +161,7 @@ Target RejectNegative Joined UInteger ID of shared library to build mshort -Target Report RejectNegative Mask(SHORT) +Target Report Mask(SHORT) Consider type 'int' to be 16 bits wide msoft-float ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 14/63] Make "long double" the same as "double" on ColdFire 2007-01-10 11:00 ` [ColdFire 13/63] Remove some RejectNegatives Richard Sandiford @ 2007-01-10 11:02 ` Richard Sandiford 2007-01-10 11:05 ` [RTL, ColdFire 15/63] Avoid out-of-segment constants on uClinux Richard Sandiford 2007-01-10 18:35 ` [ColdFire 14/63] Make "long double" the same as "double" on ColdFire Jeffrey Law 2007-01-10 18:32 ` [ColdFire 13/63] Remove some RejectNegatives Jeffrey Law 1 sibling, 2 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 11:02 UTC (permalink / raw) To: gcc-patches When we (CodeSourcery) polled ColdFire folks, there seemed to be general agreement that "long double" should be the same as "double" on ColdFire. There doesn't seem much point emulating the m68k XFmode format. This patch adjusts LONG_DOUBLE_TYPE_SIZE accordingly. It's an ABI change for all ColdFire targets. Richard gcc/ 200x-xx-xx Julian Brown <julian@codesourcery.com> * config/m68k/m68k.h (LONG_DOUBLE_TYPE_SIZE): Make 64-bit on ColdFire. (LIBGCC2_LONG_DOUBLE_TYPE_SIZE): Likewise. * config/m68k/netbsd-elf.h (LIBGCC2_LONG_DOUBLE_TYPE_SIZE): Undefine before redefining. Index: gcc/config/m68k/m68k.h =================================================================== --- gcc/config/m68k/m68k.h 2007-01-09 15:01:54.000000000 +0000 +++ gcc/config/m68k/m68k.h 2007-01-09 15:01:56.000000000 +0000 @@ -259,7 +259,17 @@ #define SUBTARGET_OVERRIDE_OPTIONS \f /* target machine storage layout */ -#define LONG_DOUBLE_TYPE_SIZE 80 +/* "long double" is the same as "double" on ColdFire targets. */ + +#define LONG_DOUBLE_TYPE_SIZE (TARGET_COLDFIRE ? 64 : 80) + +/* We need to know the size of long double at compile-time in libgcc2. */ + +#ifdef __mcoldfire__ +#define LIBGCC2_LONG_DOUBLE_TYPE_SIZE 64 +#else +#define LIBGCC2_LONG_DOUBLE_TYPE_SIZE 80 +#endif /* Set the value of FLT_EVAL_METHOD in float.h. When using 68040 fp instructions, we get proper intermediate rounding, otherwise we Index: gcc/config/m68k/netbsd-elf.h =================================================================== --- gcc/config/m68k/netbsd-elf.h 2007-01-09 15:01:51.000000000 +0000 +++ gcc/config/m68k/netbsd-elf.h 2007-01-09 15:01:56.000000000 +0000 @@ -40,6 +40,7 @@ #define TARGET_OS_CPP_BUILTINS() \ #undef LONG_DOUBLE_TYPE_SIZE #define LONG_DOUBLE_TYPE_SIZE (TARGET_68020 ? 80 : 64) +#undef LIBGCC2_LONG_DOUBLE_TYPE_SIZE #ifdef __mc68010__ #define LIBGCC2_LONG_DOUBLE_TYPE_SIZE 64 #else ^ permalink raw reply [flat|nested] 280+ messages in thread
* [RTL, ColdFire 15/63] Avoid out-of-segment constants on uClinux. 2007-01-10 11:02 ` [ColdFire 14/63] Make "long double" the same as "double" on ColdFire Richard Sandiford @ 2007-01-10 11:05 ` Richard Sandiford 2007-01-10 11:10 ` [ColdFire 16/63] Bring *-uclinux configurations closer to *-linux-gnu Richard Sandiford ` (2 more replies) 2007-01-10 18:35 ` [ColdFire 14/63] Make "long double" the same as "double" on ColdFire Jeffrey Law 1 sibling, 3 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 11:05 UTC (permalink / raw) To: gcc-patches One of the big problems with the uClinux flat format is that it cannot cope with relocations that point outside the symbol's containing segment. E.g. things like: extern unsigned char a[]; ... &a[12345 - x] ... cannot be implemented as "&a[12345] - x" because "a" might be less than 12345 bytes from the end of the segment. This problem applies to both text and data relocations: we should never emit a symbolic constant if we are unsure whether it is contained within the symbol's segment. MIPS has a similar problem for other reasons, so this patch moves two helper routines, mips_offset_within_block_p and mips_split_const, from mips.c to rtlanal.c (removing the mips_ prefixes, of course). The patch also removes the unused predicates from the movsi expander. It seems odd to handle non-legitimate operands in something that appears to be (but really isn't) guarded by *_operand predicates. One problem with this patch is that we sometimes need to access individual bytes or words of wider MEMs. This will ICE if the wider MEM has a legitimate constant address but the narrower one doesn't. This is a generic problem that applies to all addresses with limited ranges, and a later patch will fix it. FWIW, bfin_legitimate_constant_p does something similar, but it doesn't cope with constant pool entries or object blocks, neither of which the Blackfin port uses. The split_const function is similar to get_related_value and get_integer_term, but has the advantage of (a) only walking the rtl once and (b) returning an rtx offset, so that if the caller needs an rtx, it doesn't need to regenerate one from the HOST_WIDE_INT. (get_related_value and get_integer_term also cope with MINUS of a CONST_INT, but that isn't canonical rtl.) Boostrapped & regression-tested on x86_64-linux-gnu. I also compared the assembly output of mipsisa64-elf and mips64-linux-gnu for the C and C++ testsuites, using the options: -O0 -O2 -mabi=n32 -mabi=64 -mabi=eabi -mno-abicalls -mabi=32 -mabi=o64 There were no differences. I'll sign off on the MIPS bits if everything else is OK. Richard gcc/ * Makefile.in (rtlanal.o): Depend on tree.h. * rtl.h (offset_within_section_p, split_const): Declare. * rtlanal.c: Include tree.h. (offset_within_block_p): New function, taken from mips_offset_within_object_p. (split_const): New function, taken from mips_split_const. * config/m68k/m68k-protos.h (m68k_illegitimate_symbolic_constant_p): Declare. * config/m68k/m68k.h (M68K_OFFSETS_MUST_BE_WITHIN_SECTIONS_P): Define. (CONSTANT_ADDRESS_P): Only accept legitimate constants. (LEGITIMATE_CONSTANT_P): Check m68k_illegitimate_symbolic_constant_p. * config/m68k/m68k.c (TARGET_CANNOT_FORCE_CONST_MEM): Define. (m68k_illegitimate_symbolic_constant_p): New function. * config/m68k/m68k.md (movsi): Remove misleading predicates. If M68K_OFFSETS_MUST_BE_WITHIN_SECTIONS_P and the source is a symbolic constant that might be outside the symbol's section, move the symbol first and then add the offset. * config/m68k/uclinux.h (M68K_OFFSETS_MUST_BE_WITHIN_SECTIONS_P): Override. * config/mips/mips.c (mips_split_const): Delete. (mips_offset_within_object_p): Delete. (mips_symbolic_constant_p): Use offset_within_section_p and split_const instead of mips_offset_within_object_p and mips_split_const. (mips_cannot_force_const_mem, mips_const_insns, mips_unspec_address) (mips_legitimize_const_move, print_operand_reloc) (mips_dangerous_for_la25_p): Use split_const instead of mips_split_const. Index: gcc/Makefile.in =================================================================== --- gcc/Makefile.in 2007-01-09 15:01:42.000000000 +0000 +++ gcc/Makefile.in 2007-01-09 15:01:56.000000000 +0000 @@ -2189,7 +2189,7 @@ print-rtl.o : print-rtl.c $(CONFIG_H) $( $(BCONFIG_H) $(REAL_H) rtlanal.o : rtlanal.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) toplev.h \ $(RTL_H) hard-reg-set.h $(TM_P_H) insn-config.h $(RECOG_H) $(REAL_H) \ - $(FLAGS_H) $(REGS_H) output.h $(TARGET_H) $(FUNCTION_H) + $(FLAGS_H) $(REGS_H) output.h $(TARGET_H) $(FUNCTION_H) $(TREE_H) varasm.o : varasm.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) $(TREE_H) \ $(RTL_H) $(FLAGS_H) $(FUNCTION_H) $(EXPR_H) hard-reg-set.h $(REGS_H) \ Index: gcc/rtl.h =================================================================== --- gcc/rtl.h 2007-01-09 15:01:42.000000000 +0000 +++ gcc/rtl.h 2007-01-09 15:01:56.000000000 +0000 @@ -1678,6 +1678,8 @@ extern int rtx_varies_p (rtx, int); extern int rtx_addr_varies_p (rtx, int); extern HOST_WIDE_INT get_integer_term (rtx); extern rtx get_related_value (rtx); +extern bool offset_within_block_p (rtx, HOST_WIDE_INT); +extern void split_const (rtx, rtx *, rtx *); extern int reg_mentioned_p (rtx, rtx); extern int count_occurrences (rtx, rtx, int); extern int reg_referenced_p (rtx, rtx); Index: gcc/rtlanal.c =================================================================== --- gcc/rtlanal.c 2007-01-09 15:01:42.000000000 +0000 +++ gcc/rtlanal.c 2007-01-09 15:01:56.000000000 +0000 @@ -37,6 +37,7 @@ Software Foundation; either version 2, o #include "real.h" #include "regs.h" #include "function.h" +#include "tree.h" /* Information about a subreg of a hard register. */ struct subreg_info @@ -496,6 +497,61 @@ get_related_value (rtx x) return 0; } \f +/* Return true if SYMBOL is a SYMBOL_REF and OFFSET + SYMBOL points + to somewhere in the same object or object_block as SYMBOL. */ + +bool +offset_within_block_p (rtx symbol, HOST_WIDE_INT offset) +{ + tree decl; + + if (GET_CODE (symbol) != SYMBOL_REF) + return false; + + if (offset == 0) + return true; + + if (offset > 0) + { + if (CONSTANT_POOL_ADDRESS_P (symbol) + && offset < (int) GET_MODE_SIZE (get_pool_mode (symbol))) + return true; + + decl = SYMBOL_REF_DECL (symbol); + if (decl && offset < int_size_in_bytes (TREE_TYPE (decl))) + return true; + } + + if (SYMBOL_REF_HAS_BLOCK_INFO_P (symbol) + && SYMBOL_REF_BLOCK (symbol) + && SYMBOL_REF_BLOCK_OFFSET (symbol) >= 0 + && ((unsigned HOST_WIDE_INT) offset + SYMBOL_REF_BLOCK_OFFSET (symbol) + < (unsigned HOST_WIDE_INT) SYMBOL_REF_BLOCK (symbol)->size)) + return true; + + return false; +} + +/* Split X into a base and a constant offset, storing them in *BASE_OUT + and *OFFSET_OUT respectively. */ + +void +split_const (rtx x, rtx *base_out, rtx *offset_out) +{ + if (GET_CODE (x) == CONST) + { + x = XEXP (x, 0); + if (GET_CODE (x) == PLUS && GET_CODE (XEXP (x, 1)) == CONST_INT) + { + *base_out = XEXP (x, 0); + *offset_out = XEXP (x, 1); + return; + } + } + *base_out = x; + *offset_out = const0_rtx; +} +\f /* Return the number of places FIND appears within X. If COUNT_DEST is zero, we do not count occurrences inside the destination of a SET. */ Index: gcc/config/m68k/m68k-protos.h =================================================================== --- gcc/config/m68k/m68k-protos.h 2007-01-09 15:01:54.000000000 +0000 +++ gcc/config/m68k/m68k-protos.h 2007-01-09 15:01:56.000000000 +0000 @@ -49,6 +49,7 @@ extern int standard_68881_constant_p (rt extern void print_operand_address (FILE *, rtx); extern void print_operand (FILE *, rtx, int); extern void notice_update_cc (rtx, rtx); +extern bool m68k_illegitimate_symbolic_constant_p (rtx); extern rtx legitimize_pic_address (rtx, enum machine_mode, rtx); extern int valid_dbcc_comparison_p_2 (rtx, enum machine_mode); extern rtx m68k_libcall_value (enum machine_mode); Index: gcc/config/m68k/m68k.h =================================================================== --- gcc/config/m68k/m68k.h 2007-01-09 15:01:56.000000000 +0000 +++ gcc/config/m68k/m68k.h 2007-01-09 15:01:56.000000000 +0000 @@ -770,17 +770,25 @@ #define FP_REG_P(X) (REG_P (X) && REGNO_ /* 1 if X is an address register */ #define ADDRESS_REG_P(X) (REG_P (X) && REGNO_OK_FOR_BASE_P (REGNO (X))) \f +/* True if SYMBOL + OFFSET constants must refer to something within + SYMBOL's section. */ +#ifndef M68K_OFFSETS_MUST_BE_WITHIN_SECTIONS_P +#define M68K_OFFSETS_MUST_BE_WITHIN_SECTIONS_P 0 +#endif #define MAX_REGS_PER_ADDRESS 2 -#define CONSTANT_ADDRESS_P(X) \ - (GET_CODE (X) == LABEL_REF || GET_CODE (X) == SYMBOL_REF \ - || GET_CODE (X) == CONST_INT || GET_CODE (X) == CONST \ - || GET_CODE (X) == HIGH) +#define CONSTANT_ADDRESS_P(X) \ + ((GET_CODE (X) == LABEL_REF || GET_CODE (X) == SYMBOL_REF \ + || GET_CODE (X) == CONST_INT || GET_CODE (X) == CONST \ + || GET_CODE (X) == HIGH) \ + && LEGITIMATE_CONSTANT_P (X)) /* Nonzero if the constant value X is a legitimate general operand. It is given that X satisfies CONSTANT_P or is a CONST_DOUBLE. */ -#define LEGITIMATE_CONSTANT_P(X) (GET_MODE (X) != XFmode) +#define LEGITIMATE_CONSTANT_P(X) \ + (GET_MODE (X) != XFmode \ + && !m68k_illegitimate_symbolic_constant_p (X)) #ifndef REG_OK_STRICT #define PCREL_GENERAL_OPERAND_OK 0 Index: gcc/config/m68k/m68k.c =================================================================== --- gcc/config/m68k/m68k.c 2007-01-09 15:01:54.000000000 +0000 +++ gcc/config/m68k/m68k.c 2007-01-09 15:01:56.000000000 +0000 @@ -192,6 +192,9 @@ #define TARGET_PROMOTE_PROTOTYPES hook_b #undef TARGET_STRUCT_VALUE_RTX #define TARGET_STRUCT_VALUE_RTX m68k_struct_value_rtx +#undef TARGET_CANNOT_FORCE_CONST_MEM +#define TARGET_CANNOT_FORCE_CONST_MEM m68k_illegitimate_symbolic_constant_p + static const struct attribute_spec m68k_attribute_table[] = { /* { name, min_len, max_len, decl_req, type_req, fn_type_req, handler } */ @@ -1650,6 +1653,23 @@ output_btst (rtx *operands, rtx countop, return "btst %0,%1"; } \f +/* Return true if X is an illegitimate symbolic constant. */ + +bool +m68k_illegitimate_symbolic_constant_p (rtx x) +{ + rtx base, offset; + + if (M68K_OFFSETS_MUST_BE_WITHIN_SECTIONS_P) + { + split_const (x, &base, &offset); + if (GET_CODE (base) == SYMBOL_REF + && !offset_within_block_p (base, INTVAL (offset))) + return true; + } + return false; +} + /* Legitimize PIC addresses. If the address is already position-independent, we return ORIG. Newly generated position-independent addresses go to REG. If we need more Index: gcc/config/m68k/m68k.md =================================================================== --- gcc/config/m68k/m68k.md 2007-01-09 15:01:53.000000000 +0000 +++ gcc/config/m68k/m68k.md 2007-01-09 15:01:56.000000000 +0000 @@ -637,10 +637,12 @@ (define_insn "movsi_const0" ;; In both the PIC and non-PIC cases the patterns generated will ;; matched by the next define_insn. (define_expand "movsi" - [(set (match_operand:SI 0 "nonimmediate_operand" "") - (match_operand:SI 1 "general_operand" ""))] + [(set (match_operand:SI 0 "" "") + (match_operand:SI 1 "" ""))] "" { + rtx tmp, base, offset; + if (flag_pic && !TARGET_PCREL && symbolic_operand (operands[1], SImode)) { /* The source is an address which requires PIC relocation. @@ -661,6 +663,18 @@ (define_expand "movsi" operands[0] = gen_rtx_MEM (SImode, force_reg (SImode, XEXP (operands[0], 0))); } + if (M68K_OFFSETS_MUST_BE_WITHIN_SECTIONS_P) + { + split_const (operands[1], &base, &offset); + if (GET_CODE (base) == SYMBOL_REF + && !offset_within_block_p (base, INTVAL (offset))) + { + tmp = no_new_pseudos ? operands[0] : gen_reg_rtx (SImode); + emit_move_insn (tmp, base); + emit_insn (gen_addsi3 (operands[0], tmp, offset)); + DONE; + } + } }) ;; General case of fullword move. The register constraints Index: gcc/config/m68k/uclinux.h =================================================================== --- gcc/config/m68k/uclinux.h 2007-01-09 15:01:42.000000000 +0000 +++ gcc/config/m68k/uclinux.h 2007-01-09 15:01:56.000000000 +0000 @@ -63,3 +63,8 @@ #define TARGET_OS_CPP_BUILTINS() \ } \ while (0) +/* The uclinux binary format relies on relocations against a segment being + within that segment. Conservatively apply this rule to individual + sections. */ +#undef M68K_OFFSETS_MUST_BE_WITHIN_SECTIONS_P +#define M68K_OFFSETS_MUST_BE_WITHIN_SECTIONS_P 1 Index: gcc/config/mips/mips.c =================================================================== --- gcc/config/mips/mips.c 2007-01-09 15:01:42.000000000 +0000 +++ gcc/config/mips/mips.c 2007-01-09 15:01:56.000000000 +0000 @@ -267,8 +267,6 @@ struct mips_integer_op; struct mips_sim; static enum mips_symbol_type mips_classify_symbol (rtx); -static void mips_split_const (rtx, rtx *, HOST_WIDE_INT *); -static bool mips_offset_within_object_p (rtx, HOST_WIDE_INT); static bool mips_valid_base_register_p (rtx, enum machine_mode, int); static bool mips_symbolic_address_p (enum mips_symbol_type, enum machine_mode); static bool mips_classify_address (struct mips_address_info *, rtx, @@ -1311,58 +1309,6 @@ mips_classify_symbol (rtx x) return SYMBOL_GENERAL; } - -/* Split X into a base and a constant offset, storing them in *BASE - and *OFFSET respectively. */ - -static void -mips_split_const (rtx x, rtx *base, HOST_WIDE_INT *offset) -{ - *offset = 0; - - if (GET_CODE (x) == CONST) - { - x = XEXP (x, 0); - if (GET_CODE (x) == PLUS && GET_CODE (XEXP (x, 1)) == CONST_INT) - { - *offset += INTVAL (XEXP (x, 1)); - x = XEXP (x, 0); - } - } - *base = x; -} - - -/* Return true if SYMBOL is a SYMBOL_REF and OFFSET + SYMBOL points - to the same object as SYMBOL, or to the same object_block. */ - -static bool -mips_offset_within_object_p (rtx symbol, HOST_WIDE_INT offset) -{ - if (GET_CODE (symbol) != SYMBOL_REF) - return false; - - if (CONSTANT_POOL_ADDRESS_P (symbol) - && offset >= 0 - && offset < (int) GET_MODE_SIZE (get_pool_mode (symbol))) - return true; - - if (SYMBOL_REF_DECL (symbol) != 0 - && offset >= 0 - && offset < int_size_in_bytes (TREE_TYPE (SYMBOL_REF_DECL (symbol)))) - return true; - - if (SYMBOL_REF_HAS_BLOCK_INFO_P (symbol) - && SYMBOL_REF_BLOCK (symbol) - && SYMBOL_REF_BLOCK_OFFSET (symbol) >= 0 - && ((unsigned HOST_WIDE_INT) offset + SYMBOL_REF_BLOCK_OFFSET (symbol) - < (unsigned HOST_WIDE_INT) SYMBOL_REF_BLOCK (symbol)->size)) - return true; - - return false; -} - - /* Return true if X is a symbolic constant that can be calculated in the same way as a bare symbol. If it is, store the type of the symbol in *SYMBOL_TYPE. */ @@ -1370,9 +1316,9 @@ mips_offset_within_object_p (rtx symbol, bool mips_symbolic_constant_p (rtx x, enum mips_symbol_type *symbol_type) { - HOST_WIDE_INT offset; + rtx offset; - mips_split_const (x, &x, &offset); + split_const (x, &x, &offset); if (UNSPEC_ADDRESS_P (x)) *symbol_type = UNSPEC_ADDRESS_TYPE (x); else if (GET_CODE (x) == SYMBOL_REF || GET_CODE (x) == LABEL_REF) @@ -1384,7 +1330,7 @@ mips_symbolic_constant_p (rtx x, enum mi else return false; - if (offset == 0) + if (offset == const0_rtx) return true; /* Check whether a nonzero offset is valid for the underlying @@ -1400,7 +1346,7 @@ mips_symbolic_constant_p (rtx x, enum mi sign-extended. In this case we can't allow an arbitrary offset in case the 32-bit value X + OFFSET has a different sign from X. */ if (Pmode == DImode && !ABI_HAS_64BIT_SYMBOLS) - return mips_offset_within_object_p (x, offset); + return offset_within_block_p (x, INTVAL (offset)); /* In other cases the relocations can handle any offset. */ return true; @@ -1416,15 +1362,15 @@ mips_symbolic_constant_p (rtx x, enum mi case SYMBOL_SMALL_DATA: /* Make sure that the offset refers to something within the - underlying object. This should guarantee that the final + same object block. This should guarantee that the final PC- or GP-relative offset is within the 16-bit limit. */ - return mips_offset_within_object_p (x, offset); + return offset_within_block_p (x, INTVAL (offset)); case SYMBOL_GOT_LOCAL: case SYMBOL_GOTOFF_PAGE: /* The linker should provide enough local GOT entries for a 16-bit offset. Larger offsets may lead to GOT overflow. */ - return SMALL_OPERAND (offset); + return SMALL_INT (offset); case SYMBOL_GOT_GLOBAL: case SYMBOL_GOTOFF_GLOBAL: @@ -1614,8 +1560,7 @@ mips_tls_symbol_ref_1 (rtx *x, void *dat static bool mips_cannot_force_const_mem (rtx x) { - rtx base; - HOST_WIDE_INT offset; + rtx base, offset; if (!TARGET_MIPS16) { @@ -1631,8 +1576,8 @@ mips_cannot_force_const_mem (rtx x) if (GET_CODE (x) == CONST_INT) return true; - mips_split_const (x, &base, &offset); - if (symbolic_operand (base, VOIDmode) && SMALL_OPERAND (offset)) + split_const (x, &base, &offset); + if (symbolic_operand (base, VOIDmode) && SMALL_INT (offset)) return true; } @@ -1819,7 +1764,7 @@ mips_const_insns (rtx x) { struct mips_integer_op codes[MIPS_MAX_INTEGER_OPS]; enum mips_symbol_type symbol_type; - HOST_WIDE_INT offset; + rtx offset; switch (GET_CODE (x)) { @@ -1860,16 +1805,16 @@ mips_const_insns (rtx x) /* Otherwise try splitting the constant into a base and offset. 16-bit offsets can be added using an extra addiu. Larger offsets must be calculated separately and then added to the base. */ - mips_split_const (x, &x, &offset); + split_const (x, &x, &offset); if (offset != 0) { int n = mips_const_insns (x); if (n != 0) { - if (SMALL_OPERAND (offset)) + if (SMALL_INT (offset)) return n + 1; else - return n + 1 + mips_build_integer (codes, offset); + return n + 1 + mips_build_integer (codes, INTVAL (offset)); } } return 0; @@ -1968,13 +1913,14 @@ mips_split_symbol (rtx temp, rtx addr) rtx mips_unspec_address (rtx address, enum mips_symbol_type symbol_type) { - rtx base; - HOST_WIDE_INT offset; + rtx base, offset; - mips_split_const (address, &base, &offset); + split_const (address, &base, &offset); base = gen_rtx_UNSPEC (Pmode, gen_rtvec (1, base), UNSPEC_ADDRESS_FIRST + symbol_type); - return plus_constant (gen_rtx_CONST (Pmode, base), offset); + if (offset != const0_rtx) + base = gen_rtx_PLUS (Pmode, base, offset); + return gen_rtx_CONST (Pmode, base); } @@ -2322,8 +2268,7 @@ mips_move_integer (rtx dest, rtx temp, u static void mips_legitimize_const_move (enum machine_mode mode, rtx dest, rtx src) { - rtx base; - HOST_WIDE_INT offset; + rtx base, offset; /* Split moves of big integers into smaller pieces. */ if (splittable_const_int_operand (src, mode)) @@ -2348,13 +2293,13 @@ mips_legitimize_const_move (enum machine /* If we have (const (plus symbol offset)), load the symbol first and then add in the offset. This is usually better than forcing the constant into memory, at least in non-mips16 code. */ - mips_split_const (src, &base, &offset); + split_const (src, &base, &offset); if (!TARGET_MIPS16 - && offset != 0 - && (!no_new_pseudos || SMALL_OPERAND (offset))) + && offset != const0_rtx + && (!no_new_pseudos || SMALL_INT (offset))) { base = mips_force_temporary (dest, base); - emit_move_insn (dest, mips_add_offset (0, base, offset)); + emit_move_insn (dest, mips_add_offset (0, base, INTVAL (offset))); return; } @@ -5728,16 +5673,15 @@ print_operand_reloc (FILE *file, rtx op, { enum mips_symbol_type symbol_type; const char *p; - rtx base; - HOST_WIDE_INT offset; + rtx base, offset; if (!mips_symbolic_constant_p (op, &symbol_type) || relocs[symbol_type] == 0) fatal_insn ("PRINT_OPERAND, invalid operand for relocation", op); /* If OP uses an UNSPEC address, we want to print the inner symbol. */ - mips_split_const (op, &base, &offset); + split_const (op, &base, &offset); if (UNSPEC_ADDRESS_P (base)) - op = plus_constant (UNSPEC_ADDRESS (base), offset); + op = plus_constant (UNSPEC_ADDRESS (base), INTVAL (offset)); fputs (relocs[symbol_type], file); output_addr_const (file, op); @@ -7713,12 +7657,12 @@ mips_cannot_change_mode_class (enum mach bool mips_dangerous_for_la25_p (rtx x) { - HOST_WIDE_INT offset; + rtx offset; if (TARGET_EXPLICIT_RELOCS) return false; - mips_split_const (x, &x, &offset); + split_const (x, &x, &offset); return global_got_operand (x, VOIDmode); } ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 16/63] Bring *-uclinux configurations closer to *-linux-gnu 2007-01-10 11:05 ` [RTL, ColdFire 15/63] Avoid out-of-segment constants on uClinux Richard Sandiford @ 2007-01-10 11:10 ` Richard Sandiford 2007-01-10 11:13 ` [ColdFire 17/63] Assorted uClinux improvements Richard Sandiford ` (2 more replies) 2007-01-11 4:53 ` [RTL, ColdFire 15/63] Avoid out-of-segment constants on uClinux Roger Sayle 2007-01-11 17:15 ` Jeffrey Law 2 siblings, 3 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 11:10 UTC (permalink / raw) To: gcc-patches The next patch in the series will make some major changes to the uClinux support. The idea is to make it seem more like a full ELF (GNU or non-GNU) linux target. However, the current uClinux configuration is a form of *-elf rather than *-linux-gnu. This leads to two important incompatibilities: - *-linux-gnu returns pointers in %a0 while *-uclinux returns then in %d0. - *-linux-gnu uses %a1 as the incoming return address while *-uclinux uses %a0. It seems odd to have this sort of difference. I would generally have expected *-uclinux and *-linux* to have the same calling convention, as the two are often source-compatible otherwise (even at the assembly level). If we're making the major changes mentioned above anyway, and if we're changing the ABI by redefining long double, it seems like a good idea to remove this incompatibility too, and make *-linux-gnu and *-uclinux variants of one another. This patch therefore makes *-uclinux include the linux headers and makefiles, then override the uClinux-specific bits. As well as removing the incompabilities just mentioned, the patch pulls in some useful things from the linux support. For example, the linux trampoline code uses a cacheflush syscall, whereas the current uClinux configuration is not cache-friendly. Richard gcc/ * config.gcc (m68k-*-uclinux*): Base the port on the common and m68k GNU/Linux files rather than on the generic ELF ones. * config/m68k/uclinux.h (TARGET_VERSION): Override. (TARGET_OS_CPP_BUILTINS): Use LINUX_TARGET_OS_CPP_BUILTINS. Index: gcc/config.gcc =================================================================== --- gcc/config.gcc 2007-01-09 15:01:52.000000000 +0000 +++ gcc/config.gcc 2007-01-09 15:01:58.000000000 +0000 @@ -1505,8 +1505,9 @@ m68k*-*-openbsd*) ;; m68k-*-uclinux*) # Motorola m68k/ColdFire running uClinux with uClibc default_m68k_cpu=68020 - tm_file="m68k/m68k.h m68k/m68k-none.h m68k/m68kelf.h dbxelf.h elfos.h m68k/uclinux.h" - tm_defines="${tm_defines} MOTOROLA USE_GAS" + tm_file="m68k/m68k.h dbxelf.h elfos.h svr4.h linux.h m68k/linux.h m68k/uclinux.h" + tm_defines="${tm_defines} MOTOROLA USE_GAS UCLIBC_DEFAULT=1" + extra_options="${extra_options} linux.opt" tmake_file=m68k/t-uclinux use_fixproto=no ;; Index: gcc/config/m68k/uclinux.h =================================================================== --- gcc/config/m68k/uclinux.h 2007-01-09 15:01:56.000000000 +0000 +++ gcc/config/m68k/uclinux.h 2007-01-09 15:01:58.000000000 +0000 @@ -21,6 +21,8 @@ the Free Software Foundation; either ver the Free Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. */ +#undef TARGET_VERSION +#define TARGET_VERSION fprintf (stderr, " (68k uClinux)"); /* Undo the definition of STARTFILE_SPEC from m68kelf.h so we'll pick the default from gcc.c (just link crt0.o from multilib dir). */ @@ -45,22 +47,15 @@ #define EH_FRAME_IN_DATA_SECTION #undef ENDFILE_SPEC #define ENDFILE_SPEC "" -/* Bring in standard linux defines */ #undef TARGET_OS_CPP_BUILTINS -#define TARGET_OS_CPP_BUILTINS() \ - do \ - { \ - builtin_define_std ("mc68000"); \ - builtin_define ("__uClinux__"); \ - builtin_define_std ("linux"); \ - builtin_define_std ("unix"); \ - builtin_define ("__gnu_linux__"); \ - builtin_assert ("system=linux"); \ - builtin_assert ("system=unix"); \ - builtin_assert ("system=posix"); \ - if (TARGET_ID_SHARED_LIBRARY) \ - builtin_define ("__ID_SHARED_LIBRARY__"); \ - } \ +#define TARGET_OS_CPP_BUILTINS() \ + do \ + { \ + LINUX_TARGET_OS_CPP_BUILTINS (); \ + builtin_define ("__uClinux__"); \ + if (TARGET_ID_SHARED_LIBRARY) \ + builtin_define ("__ID_SHARED_LIBRARY__"); \ + } \ while (0) /* The uclinux binary format relies on relocations against a segment being ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 17/63] Assorted uClinux improvements 2007-01-10 11:10 ` [ColdFire 16/63] Bring *-uclinux configurations closer to *-linux-gnu Richard Sandiford @ 2007-01-10 11:13 ` Richard Sandiford 2007-01-10 11:15 ` [ColdFire 18/63] Configuration cleanups Richard Sandiford 2007-01-10 21:29 ` [ColdFire 17/63] Assorted uClinux improvements Jeffrey Law 2007-01-10 19:21 ` [ColdFire 16/63] Bring *-uclinux configurations closer to *-linux-gnu Christoph Hellwig 2007-01-10 21:24 ` Jeffrey Law 2 siblings, 2 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 11:13 UTC (permalink / raw) To: gcc-patches This patch makes several related changes to the uClinux supprt. It: - Converts the port to use .init and .fini sections. - Uses an .eh_frame section. - Prevents the PT_GNU_EH_FRAME code from being used. The flat file format has no equivalent of PT_GNU_EH_FRAME. - Prevents EH data from using indirect references for code and global data references if -msep-data or -mid-shared-library-id are being used. See the comment in the patch for details. - Maps -mid-shared-library=N to elf2flt's -shared-lib-id N. This removes the need to pass -Wl,-shared-lib-id,N separately. - Makes typeinfo comparisons work across shared library boundaries. Flat executables and shared libraries do not share typeinfo names. - Moves the -elf2flt linker option from LIB_SPEC to LINK_SPEC (it isn't a library spec) and suppresses it if the user passes -elf2flt or -elf2flt=* themselves. This is just a clean-up. - Maps the normal PIC options to -msep-data, as -msep-data is the default PIC mode on this target. - Fixes the PICCALL and PICJUMP macros in lb1sf68.asm so that they can cope with offsets greater than 16 bits on ISA A and A+ ColdFire targets (which have no bsr.l or bra.l). - Changes the -fPIC error from: if (!TARGET_68020 && !TARGET_COLDFIRE && (flag_pic == 2)) error ("-fPIC is not currently supported on the 68000 or 68010"); to: if (TARGET_PCREL && !TARGET_68020 && flag_pic == 2) error ("-mpcrel -fPIC is not currently supported on selected cpu"); The old code is misleading: there's nothing special about ColdFire that makes its -fPIC support better than that for plain 68000. Both targets are restricted to 16-bit offsets. Stepping back a bit, the m68k port has two main types of PIC: GOT-based PIC and -mpcrel. In the former case, the port will only generate 32-bit offsets if both TARGET_68020 and flag_pic == 2 are true, otherwise it will generate 16-bit offsets. A 16-bit offset is often enough, so a hard error isn't really appropriate for any target. -mpcrel is different. A 16-bit PC-relative offset is very limiting, so it seems reasonable to give a hard error if 32-bit offsets are not supported. - Updates the start and end files to work with uClibc head. See: http://www.busybox.net/lists/uclibc/2006-July/015892.html for details and rationale. As described in that message, one of the motivations for this change is that you can now create shared libraries with a command line like: m68k-uclinux-gcc -mid-shared-library -mshared-library-id=N \ -o libfoo ...inputs... instead of something like: ar -r libfoo.a ...inputs... m68k-*-gcc -o libfoo -nostartfiles -mid-shared-library \ [other flags definitions and includes] \ -Wl,-elf2flt -nostdlib \ -Wl,-shared-lib-id,3 \ ${UCLINUXDIST}/uClibc/lib/main.o \ -Wl,--whole-archive,libfoo.a,-lgcc,--no-whole-archive m68k-elf-objcopy \ -L _GLOBAL_OFFSET_TABLE_ \ -L main \ -L __main \ -L lib_main \ -L __do_global_dtors \ -L __do_global_ctors \ -L __CTOR_LIST__ \ -L __DTOR_LIST__ \ -L _current_shared_library_a5_offset_ \ libfoo.gdb which was the previously-recommended sequence. Richard gcc/ * config.gcc (m68k-*-uclinux*): Add flat.h to $tm_file. * config/flat.h: New file. * crtstuff.c (USE_PT_GNU_EH_FRAME): Don't define if OBJECT_FORMAT_FLAT. * config/m68k/m68k.h (ASM_PREFERRED_EH_DATA_FORMAT): Do not use indirect references for -msep-data or -mid-shared-library. Do not use PC-relative code addresses either. * config/m68k/m68k.c (override_options): Restrict -fPIC error to -mpcrel. * config/m68k/uclinux.h (STARTFILE_SPEC): Define. Use Scrt1.o for shared libraries and crt1.o for executables. Use crti.o and crtbegin.o. (ENDFILE_SPEC): Use crtend.o and crtn.o. (LIB_SPEC): Suppress -Rlibc.gdb if -static-libc is given. Do not add -elf2flt or -shared-lib-id options here. (LINK_SPEC): Define. Pass -elf2flt if no -elf2flt option is given. Pass -shared-lib-id if -mid-shared-library, taking the library identifier from -mshared-library-id if given, otherwise defaulting to 0. (EH_FRAME_IN_DATA_SECTION): Do not undefine. (INIT_SECTION_ASM_OP, FINI_SECTION_ASM_OP): Likewise. (TARGET_OS_CPP_BUILTINS): Define __GXX_MERGED_TYPEINFO_NAMES=0 and __GXX_TYPEINFO_EQUALITY_INLINE=0 if -mid-shared-library. (DRIVER_SELF_SPECS): Map unadorned PIC options to -msep-data. * config/m68k/t-uclinux (EXTRA_MULTILIB_PARTS): Add crtbegin.o and crtend.o. * config/m68k/lb1sf68.asm (PICCALL): Use an lea and pc-relative jump sequence for ISA A and ISA A+. (PICJUMP): Likewise. Index: gcc/config.gcc =================================================================== --- gcc/config.gcc 2007-01-09 15:01:58.000000000 +0000 +++ gcc/config.gcc 2007-01-09 15:01:59.000000000 +0000 @@ -1505,7 +1505,7 @@ m68k*-*-openbsd*) ;; m68k-*-uclinux*) # Motorola m68k/ColdFire running uClinux with uClibc default_m68k_cpu=68020 - tm_file="m68k/m68k.h dbxelf.h elfos.h svr4.h linux.h m68k/linux.h m68k/uclinux.h" + tm_file="m68k/m68k.h dbxelf.h elfos.h svr4.h linux.h flat.h m68k/linux.h m68k/uclinux.h" tm_defines="${tm_defines} MOTOROLA USE_GAS UCLIBC_DEFAULT=1" extra_options="${extra_options} linux.opt" tmake_file=m68k/t-uclinux Index: gcc/config/flat.h =================================================================== --- /dev/null 2007-01-09 03:39:34.548096750 +0000 +++ gcc/config/flat.h 2007-01-09 15:01:59.000000000 +0000 @@ -0,0 +1,23 @@ +/* Defines to be used for targets that support flat executables. + Copyright (C) 2006 Free Software Foundation, Inc. + +This file is part of GCC. + +GCC is free software; you can redistribute it and/or modify +it under the terms of the GNU General Public License as published by +the Free Software Foundation; either version 2, or (at your option) +any later version. + +GCC is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. + +You should have received a copy of the GNU General Public License +along with GCC; see the file COPYING. If not, write to +the Free Software Foundation, 51 Franklin Street, Fifth Floor, +Boston, MA 02110-1301, USA. */ + +/* This macro applies on top of OBJECT_FORMAT_ELF and indicates that + we want to support both flat and ELF output. */ +#define OBJECT_FORMAT_FLAT Index: gcc/crtstuff.c =================================================================== --- gcc/crtstuff.c 2007-01-09 15:01:42.000000000 +0000 +++ gcc/crtstuff.c 2007-01-09 15:01:59.000000000 +0000 @@ -86,7 +86,9 @@ call_ ## FUNC (void) \ } #endif -#if defined(OBJECT_FORMAT_ELF) && defined(HAVE_LD_EH_FRAME_HDR) \ +#if defined(OBJECT_FORMAT_ELF) \ + && !defined(OBJECT_FORMAT_FLAT) \ + && defined(HAVE_LD_EH_FRAME_HDR) \ && !defined(inhibit_libc) && !defined(CRTSTUFFT_O) \ && defined(__GLIBC__) && __GLIBC__ >= 2 #include <link.h> Index: gcc/config/m68k/m68k.h =================================================================== --- gcc/config/m68k/m68k.h 2007-01-09 15:01:56.000000000 +0000 +++ gcc/config/m68k/m68k.h 2007-01-09 15:01:59.000000000 +0000 @@ -1098,9 +1098,34 @@ #define EH_RETURN_HANDLER_RTX \ /* Select a format to encode pointers in exception handling data. CODE is 0 for data, 1 for code labels, 2 for function pointers. GLOBAL is - true if the symbol may be affected by dynamic relocations. */ + true if the symbol may be affected by dynamic relocations. + + TARGET_ID_SHARED_LIBRARY and TARGET_SEP_DATA are designed to support + a read-only text segment without imposing a fixed gap between the + text and data segments. As a result, the text segment cannot refer + to anything in the data segment, even in PC-relative form. Because + .eh_frame refers to both code and data, it follows that .eh_frame + must be in the data segment itself, and that the offset between + .eh_frame and code will not be a link-time constant. + + In theory, we could create a read-only .eh_frame by using DW_EH_PE_pcrel + | DW_EH_PE_indirect for all code references. However, gcc currently + handles indirect references using a per-TU constant pool. This means + that if a function and its eh_frame are removed by the linker, the + eh_frame's indirect references to the removed function will not be + removed, leading to an unresolved symbol error. + + It isn't clear that any -msep-data or -mid-shared-library target + would benefit from a read-only .eh_frame anyway. In particular, + no known target that supports these options has a feature like + PT_GNU_RELRO. Without any such feature to motivate them, indirect + references would be unnecessary bloat, so we simply use an absolute + pointer for code and global references. We still use pc-relative + references to data, as this avoids a relocation. */ #define ASM_PREFERRED_EH_DATA_FORMAT(CODE, GLOBAL) \ (flag_pic \ + && !((TARGET_ID_SHARED_LIBRARY || TARGET_SEP_DATA) \ + && ((GLOBAL) || (CODE))) \ ? ((GLOBAL) ? DW_EH_PE_indirect : 0) | DW_EH_PE_pcrel | DW_EH_PE_sdata4 \ : DW_EH_PE_absptr) Index: gcc/config/m68k/m68k.c =================================================================== --- gcc/config/m68k/m68k.c 2007-01-09 15:01:56.000000000 +0000 +++ gcc/config/m68k/m68k.c 2007-01-09 15:01:59.000000000 +0000 @@ -522,10 +522,10 @@ override_options (void) if (TARGET_SEP_DATA || TARGET_ID_SHARED_LIBRARY) flag_pic = 2; - /* -fPIC uses 32-bit pc-relative displacements, which don't exist - until the 68020. */ - if (!TARGET_68020 && !TARGET_COLDFIRE && (flag_pic == 2)) - error ("-fPIC is not currently supported on the 68000 or 68010"); + /* -mpcrel -fPIC uses 32-bit pc-relative displacements. Raise an + error if the target does not support them. */ + if (TARGET_PCREL && !TARGET_68020 && flag_pic == 2) + error ("-mpcrel -fPIC is not currently supported on selected cpu"); /* ??? A historic way of turning on pic, or is this intended to be an embedded thing that doesn't have the same name binding Index: gcc/config/m68k/uclinux.h =================================================================== --- gcc/config/m68k/uclinux.h 2007-01-09 15:01:58.000000000 +0000 +++ gcc/config/m68k/uclinux.h 2007-01-09 15:01:59.000000000 +0000 @@ -24,29 +24,27 @@ the Free Software Foundation; either ver #undef TARGET_VERSION #define TARGET_VERSION fprintf (stderr, " (68k uClinux)"); -/* Undo the definition of STARTFILE_SPEC from m68kelf.h so we'll - pick the default from gcc.c (just link crt0.o from multilib dir). */ -#undef STARTFILE_SPEC +#undef STARTFILE_SPEC +#define STARTFILE_SPEC \ +"%{mshared-library-id=0|!mshared-library-id=*: crt1.o%s ;: Scrt1.o%s} \ + crti.o%s crtbegin.o%s" + +#undef ENDFILE_SPEC +#define ENDFILE_SPEC "crtend.o%s crtn.o%s" /* Override the default LIB_SPEC from gcc.c. We don't currently support profiling, or libg.a. */ #undef LIB_SPEC -#define LIB_SPEC "\ -%{mid-shared-library:-R libc.gdb%s -elf2flt -shared-lib-id 0} -lc \ -" - -/* we don't want a .eh_frame section. */ -#define EH_FRAME_IN_DATA_SECTION - -/* ??? Quick hack to get constructors working. Make this look more like a - COFF target, so the existing dejagnu/libgloss support works. A better - solution would be to make the necessary dejagnu and libgloss changes so - that we can use normal the ELF constructor mechanism. */ -#undef INIT_SECTION_ASM_OP -#undef FINI_SECTION_ASM_OP -#undef ENDFILE_SPEC -#define ENDFILE_SPEC "" - +#define LIB_SPEC \ +"%{mid-shared-library:%{!static-libc:-R libc.gdb%s}} -lc" + +/* Default to using -elf2flt with no options. */ +#undef LINK_SPEC +#define LINK_SPEC \ +"%{!elf2flt*:-elf2flt} \ + %{mid-shared-library: \ + %{mshared-library-id=*:-shared-lib-id %*;:-shared-lib-id 0}}" + #undef TARGET_OS_CPP_BUILTINS #define TARGET_OS_CPP_BUILTINS() \ do \ @@ -54,7 +52,13 @@ #define TARGET_OS_CPP_BUILTINS() \ LINUX_TARGET_OS_CPP_BUILTINS (); \ builtin_define ("__uClinux__"); \ if (TARGET_ID_SHARED_LIBRARY) \ - builtin_define ("__ID_SHARED_LIBRARY__"); \ + { \ + builtin_define ("__ID_SHARED_LIBRARY__"); \ + /* Shared libraries and executables do not share \ + typeinfo names. */ \ + builtin_define ("__GXX_MERGED_TYPEINFO_NAMES=0"); \ + builtin_define ("__GXX_TYPEINFO_EQUALITY_INLINE=0"); \ + } \ } \ while (0) @@ -63,3 +67,7 @@ #define TARGET_OS_CPP_BUILTINS() \ sections. */ #undef M68K_OFFSETS_MUST_BE_WITHIN_SECTIONS_P #define M68K_OFFSETS_MUST_BE_WITHIN_SECTIONS_P 1 + +/* -msep-data is the default PIC mode on this target. */ +#define DRIVER_SELF_SPECS \ + "%{fpie|fPIE|fpic|fPIC:%{!msep-data:%{!mid-shared-library: -msep-data}}}" Index: gcc/config/m68k/t-uclinux =================================================================== --- gcc/config/m68k/t-uclinux 2007-01-09 15:01:41.000000000 +0000 +++ gcc/config/m68k/t-uclinux 2007-01-09 15:01:59.000000000 +0000 @@ -1,3 +1,6 @@ +# crti and crtn are provided by uClibc. +EXTRA_MULTILIB_PARTS=crtbegin.o crtend.o + LIB1ASMSRC = m68k/lb1sf68.asm LIB1ASMFUNCS = _mulsi3 _udivsi3 _divsi3 _umodsi3 _modsi3 \ _double _float _floatex \ @@ -19,6 +22,3 @@ MULTILIB_EXCEPTIONS = m68000/msep-data* LIBGCC = stmp-multilib INSTALL_LIBGCC = install-multilib - -# We don't use crtbegin.o and crtend.o -EXTRA_MULTILIB_PARTS= Index: gcc/config/m68k/lb1sf68.asm =================================================================== --- gcc/config/m68k/lb1sf68.asm 2007-01-09 15:01:41.000000000 +0000 +++ gcc/config/m68k/lb1sf68.asm 2007-01-09 15:01:59.000000000 +0000 @@ -120,11 +120,21 @@ Boston, MA 02110-1301, USA. */ /* Common for -mid-shared-libary and -msep-data */ .macro PICCALL addr +#if defined (__mcoldfire__) && !defined (__mcfisab__) + lea \addr-.-8,a0 + jsr pc@(a0) +#else bsr \addr +#endif .endm .macro PICJUMP addr +#if defined (__mcoldfire__) && !defined (__mcfisab__) + lea \addr-.-8,a0 + jmp pc@(a0) +#else bra \addr +#endif .endm # if defined(__ID_SHARED_LIBRARY__) ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 18/63] Configuration cleanups 2007-01-10 11:13 ` [ColdFire 17/63] Assorted uClinux improvements Richard Sandiford @ 2007-01-10 11:15 ` Richard Sandiford 2007-01-10 11:16 ` [ColdFire 19/63] Make MOTOROLA a numeric macro from the outset Richard Sandiford 2007-01-10 18:51 ` [ColdFire 18/63] Configuration cleanups Jeffrey Law 2007-01-10 21:29 ` [ColdFire 17/63] Assorted uClinux improvements Jeffrey Law 1 sibling, 2 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 11:15 UTC (permalink / raw) To: gcc-patches This patch just cleans up some of the configuration header files a little. Specifically: - m68k.h defines PCC_STATIC_STRUCT_RETURN, but then every port except openbsd undefines it again. It would be simpler to define PCC_STATIC_STRUCT_RETURN in openbsd and remove the rest. It isn't clear whether the openbsd behaviour is intentional or not, but I'd rather not change it as I have no way of testing it. - REGISTER_PREFIX_MD is never used. - m68k-none.h's CC1_SPEC is not needed because "" is the default. - m68020-elf.h's LIB_SPEC is not needed. The file is always included after m68kemb.h, and its identical definition of LIB_SPEC still holds when m68020-elf.h is included. - In the same way, m68k/linux.h's definition of SIZE_TYPE, PTRDIFF_TYPE, WCHAR_TYPE and WCHAR_TYPE_SIZE are redundant with the svr4.h definitions. Its TARGET_OBJFMT_CPP_BUILTINS is redundant with the elfos.h definition. Its DBX_REGISTER_NUMBER is redundant with the m68k.h definition. - The linux.h definition of TARGET_OS_CPP_BUILTINS includes some mc680*0 macros. This code is redundant with TARGET_CPU_CPP_BUILTINS and m68020 is not correct for ColdFire targets. - m68k-elf.h's and netbsd-elf's IMMEDIATE_PREFIX definitions are not needed because "#" is the default. - m68k-elf.h's BSS_ASM_OP isn't needed because the macro is never used. - Likewise m68k-none's CPP_SUBTARGET_SPEC. - m68k-elf.h's NO_DOLLAR_IN_LABEL, ASM_OUTPUT_SKIP and ASM_OUTPUT_ASCII are dead because elfos.h overrides them. (I can imagine that the include order used to be the other way around, so I'm not sure how intentional the current situation is. We haven't seen any problems with it here though.) - Several files define ASM_OUTPUT_REG_PUSH and ASM_OUTPUT_REG_POP, but these definitions are really just hard-coding a choice of assembly dialect. We can make m68k.h define the macros for all configurations and use MOTOROLA to choose the appropriate form. Richard gcc/ 200x-xx-xx Richard Sandiford <richard@codesourcery.com> Nathan Sidwell <nathan@codesourcery.com> * config/m68k/m68k.h (PCC_STATIC_STRUCT_RETURN): Delete. (ASM_OUTPUT_REG_PUSH, ASM_OUTPUT_REG_POP): Add MOTOROLA cases. * config/m68k/coff.h (REGISTER_PREFIX_MD): Delete. * config/m68k/m68020-elf.h (LIB_SPEC): Delete. * config/m68k/m68k-none.h (CC1_SPEC, CPP_SUBTARGET_SPEC): Delete. * config/m68k/m68kelf.h (IMMEDIATE_PREFIX, REGISTER_PREFIX_MD) (ASM_OUTPUT_REG_PUSH, ASM_OUTPUT_REG_POP): Delete. (NO_DOLLAR_IN_LABEL, PCC_STATIC_STRUCT_RETURN): Don't undefine. (BSS_ASM_OP, ASM_OUTPUT_SKIP, ASM_OUTPUT_ASCII): Delete. * config/m68k/m68kemb.h (PCC_STATIC_STRUCT_RETURN): Don't undefine. * config/m68k/linux.h (SIZE_TYPE, PTRDIFF_TYPE, WCHAR_TYPE) (WCHAR_TYPE_SIZE, TARGET_OBJFMT_CPP_BUILTINS): Delete. (TARGET_OS_CPP_BUILTINS): Don't define mc68000 and mc68020 here. (DBX_REGISTER_NUMBER): Delete. * config/m68k/netbsd-elf.h (IMMEDIATE_PREFIX): Delete. (PCC_STATIC_STRUCT_RETURN): Don't undefine. * config/m68k/openbsd.h (PCC_STATIC_STRUCT_RETURN): Define. Index: gcc/config/m68k/m68k.h =================================================================== --- gcc/config/m68k/m68k.h 2007-01-09 15:01:59.000000000 +0000 +++ gcc/config/m68k/m68k.h 2007-01-09 15:02:00.000000000 +0000 @@ -625,8 +625,6 @@ #define FUNCTION_VALUE_REGNO_P(N) ((N) = XXX This macro is m68k specific and used only for m68kemb.h. */ #define NEEDS_UNTYPED_CALL 0 -#define PCC_STATIC_STRUCT_RETURN - /* On the m68k, all arguments are usually pushed on the stack. */ #define FUNCTION_ARG_REGNO_P(N) 0 \f @@ -1135,10 +1133,17 @@ #define ASM_OUTPUT_LABELREF(FILE,NAME) \ #define ASM_GENERATE_INTERNAL_LABEL(LABEL,PREFIX,NUM) \ sprintf (LABEL, "*%s%s%ld", LOCAL_LABEL_PREFIX, PREFIX, (long)(NUM)) -#define ASM_OUTPUT_REG_PUSH(FILE,REGNO) \ - asm_fprintf (FILE, "\tmovel %s,%Rsp@-\n", reg_names[REGNO]) -#define ASM_OUTPUT_REG_POP(FILE,REGNO) \ - asm_fprintf (FILE, "\tmovel %Rsp@+,%s\n", reg_names[REGNO]) +#define ASM_OUTPUT_REG_PUSH(FILE,REGNO) \ + asm_fprintf (FILE, (MOTOROLA \ + ? "\tmove.l %s,-(%Rsp)\n" \ + : "\tmovel %s,%Rsp@-\n"), \ + reg_names[REGNO]) + +#define ASM_OUTPUT_REG_POP(FILE,REGNO) \ + asm_fprintf (FILE, (MOTOROLA \ + ? "\tmove.l (%Rsp)+,%s\n" \ + : "\tmovel %Rsp@+,%s\n"), \ + reg_names[REGNO]) /* The m68k does not use absolute case-vectors, but we must define this macro anyway. */ Index: gcc/config/m68k/coff.h =================================================================== --- gcc/config/m68k/coff.h 2007-01-09 15:01:41.000000000 +0000 +++ gcc/config/m68k/coff.h 2007-01-09 15:02:00.000000000 +0000 @@ -46,12 +46,6 @@ #define LOCAL_LABEL_PREFIX "." #undef REGISTER_PREFIX #define REGISTER_PREFIX "%" -/* In the machine description we can't use %R, because it will not be seen - by ASM_FPRINTF. (Isn't that a design bug?). */ - -#undef REGISTER_PREFIX_MD -#define REGISTER_PREFIX_MD "%%" - /* config/m68k.md has an explicit reference to the program counter, prefix this by the register prefix. */ Index: gcc/config/m68k/m68020-elf.h =================================================================== --- gcc/config/m68k/m68020-elf.h 2007-01-09 15:01:41.000000000 +0000 +++ gcc/config/m68k/m68020-elf.h 2007-01-09 15:02:00.000000000 +0000 @@ -28,6 +28,4 @@ the Free Software Foundation; either ver #undef STARTFILE_SPEC #define STARTFILE_SPEC "crtbegin.o%s" -#define LIB_SPEC "-lc" - /* end of m68020-elf.h */ Index: gcc/config/m68k/m68k-none.h =================================================================== --- gcc/config/m68k/m68k-none.h 2007-01-09 15:01:51.000000000 +0000 +++ gcc/config/m68k/m68k-none.h 2007-01-09 15:02:00.000000000 +0000 @@ -21,12 +21,3 @@ the Free Software Foundation; either ver #undef ASM_SPEC #define ASM_SPEC "%(asm_cpu_spec) %{fPIC:--pcrel} %{fpic:--pcrel} \ %{msep-data:--pcrel} %{mid-shared-library:--pcrel}" - -/* cc1/cc1plus always receives all the -m flags. If the specs strings above - are consistent with the flags in m68k.opt, there should be no need for - any further cc1/cc1plus specs. */ - -#undef CC1_SPEC -#define CC1_SPEC "" - -#define CPP_SUBTARGET_SPEC "" Index: gcc/config/m68k/m68kelf.h =================================================================== --- gcc/config/m68k/m68kelf.h 2007-01-09 15:01:41.000000000 +0000 +++ gcc/config/m68k/m68kelf.h 2007-01-09 15:02:00.000000000 +0000 @@ -28,7 +28,7 @@ the Free Software Foundation; either ver #define SWBEG_ASM_OP "\t.swbeg\t" #endif -/* Here are four prefixes that are used by asm_fprintf to +/* Here are three prefixes that are used by asm_fprintf to facilitate customization for alternate assembler syntaxes. Machines with no likelihood of an alternate syntax need not define these and need not use asm_fprintf. */ @@ -51,17 +51,6 @@ #define LOCAL_LABEL_PREFIX "." #undef USER_LABEL_PREFIX #define USER_LABEL_PREFIX "" -/* The prefix for immediate operands. */ - -#undef IMMEDIATE_PREFIX -#define IMMEDIATE_PREFIX "#" - -/* In the machine description we can't use %R, because it will not be seen - by ASM_FPRINTF. (Isn't that a design bug?). */ - -#undef REGISTER_PREFIX_MD -#define REGISTER_PREFIX_MD "%%" - /* config/m68k.md has an explicit reference to the program counter, prefix this by the register prefix. */ @@ -88,39 +77,6 @@ #define ASM_OUTPUT_ALIGN(FILE,LOG) \ fprintf ((FILE), "%s%u\n", ALIGN_ASM_OP, 1 << (LOG)); \ } while (0) -/* Use proper assembler syntax for these macros. */ -#undef ASM_OUTPUT_REG_PUSH -#define ASM_OUTPUT_REG_PUSH(FILE,REGNO) \ - asm_fprintf (FILE, "\t%Omove.l %s,-(%Rsp)\n", reg_names[REGNO]) - -#undef ASM_OUTPUT_REG_POP -#define ASM_OUTPUT_REG_POP(FILE,REGNO) \ - asm_fprintf (FILE, "\t%Omove.l (%Rsp)+,%s\n", reg_names[REGNO]) - -/* Override the definition of NO_DOLLAR_IN_LABEL in svr4.h, for special - g++ assembler names. When this is defined, g++ uses embedded '.' - characters and some m68k assemblers have problems with this. The - chances are much greater that any particular assembler will permit - embedded '$' characters. */ - -#undef NO_DOLLAR_IN_LABEL - -/* Define PCC_STATIC_STRUCT_RETURN if the convention on the target machine - is to use the nonreentrant technique for returning structure and union - values, as commonly implemented by the AT&T Portable C Compiler (PCC). - When defined, the gcc option -fpcc-struct-return can be used to cause - this form to be generated. When undefined, the option does nothing. - For m68k SVR4, the convention is to use a reentrant technique compatible - with the gcc default, so override the definition of this macro in m68k.h */ - -#undef PCC_STATIC_STRUCT_RETURN - -/* Local common symbols are declared to the assembler with ".lcomm" rather - than ".bss", so override the definition in svr4.h */ - -#undef BSS_ASM_OP -#define BSS_ASM_OP "\t.lcomm\t" - /* Register in which address to store a structure value is passed to a function. The default in m68k.h is a1. For m68k/SVR4 it is a0. */ @@ -137,16 +93,6 @@ #define ASM_COMMENT_START "|" #undef DBX_REGISTER_NUMBER #define DBX_REGISTER_NUMBER(REGNO) (REGNO) -/* The ASM_OUTPUT_SKIP macro is first defined in m68k.h, using ".skip". - It is then overridden by m68k/sgs.h to use ".space", and again by svr4.h - to use ".zero". The m68k/SVR4 assembler uses ".space", so repeat the - definition from m68k/sgs.h here. Note that ASM_NO_SKIP_IN_TEXT is - defined in m68k/sgs.h, so we don't have to repeat it here. */ - -#undef ASM_OUTPUT_SKIP -#define ASM_OUTPUT_SKIP(FILE,SIZE) \ - fprintf (FILE, "%s%u\n", SPACE_ASM_OP, (int)(SIZE)) - #if 0 /* SVR4 m68k assembler is bitching on the `comm i,1,1' which askes for 1 byte alignment. Don't generate alignment for COMMON seems to be @@ -156,39 +102,6 @@ #define ASM_OUTPUT_SKIP(FILE,SIZE) \ #undef ASM_OUTPUT_ALIGNED_LOCAL #endif -/* The `string' directive on m68k svr4 does not handle string with - escape char (i.e., `\') right. Use normal way to output ASCII bytes - seems to be safer. */ -#undef ASM_OUTPUT_ASCII -#define ASM_OUTPUT_ASCII(FILE,PTR,LEN) \ -do { \ - register int sp = 0, ch; \ - fputs (integer_asm_op (1, TRUE), (FILE)); \ - do { \ - ch = (PTR)[sp]; \ - if (ch > ' ' && ! (ch & 0x80) && ch != '\\') \ - { \ - fprintf ((FILE), "'%c", ch); \ - } \ - else \ - { \ - fprintf ((FILE), "0x%x", ch); \ - } \ - if (++sp < (LEN)) \ - { \ - if ((sp % 10) == 0) \ - { \ - fprintf ((FILE), "\n%s", integer_asm_op (1, TRUE)); \ - } \ - else \ - { \ - putc (',', (FILE)); \ - } \ - } \ - } while (sp < (LEN)); \ - putc ('\n', (FILE)); \ -} while (0) - #undef ASM_OUTPUT_COMMON #undef ASM_OUTPUT_LOCAL #define ASM_OUTPUT_COMMON(FILE, NAME, SIZE, ROUNDED) \ Index: gcc/config/m68k/m68kemb.h =================================================================== --- gcc/config/m68k/m68kemb.h 2007-01-09 15:01:41.000000000 +0000 +++ gcc/config/m68k/m68kemb.h 2007-01-09 15:02:00.000000000 +0000 @@ -14,10 +14,6 @@ #define SIZE_TYPE "long unsigned int" so we define PCC_BITFIELD_TYPE_MATTERS. */ #define PCC_BITFIELD_TYPE_MATTERS 1 -/* Undef PCC_STATIC_STRUCT_RETURN so that we get a re-entrant calling - convention. */ -#undef PCC_STATIC_STRUCT_RETURN - /* Don't default to pcc-struct-return, so that we can return small structures and unions in registers, which is slightly more efficient. */ #define DEFAULT_PCC_STRUCT_RETURN 0 Index: gcc/config/m68k/linux.h =================================================================== --- gcc/config/m68k/linux.h 2007-01-09 15:01:51.000000000 +0000 +++ gcc/config/m68k/linux.h 2007-01-09 15:02:00.000000000 +0000 @@ -58,34 +58,8 @@ #define USER_LABEL_PREFIX "" #define ASM_COMMENT_START "|" -#undef SIZE_TYPE -#define SIZE_TYPE "unsigned int" - -#undef PTRDIFF_TYPE -#define PTRDIFF_TYPE "int" - -#undef WCHAR_TYPE -#define WCHAR_TYPE "long int" - -#undef WCHAR_TYPE_SIZE -#define WCHAR_TYPE_SIZE BITS_PER_WORD - /* Target OS builtins. */ -#define TARGET_OS_CPP_BUILTINS() \ - do \ - { \ - LINUX_TARGET_OS_CPP_BUILTINS(); \ - builtin_define_std ("mc68000"); \ - builtin_define_std ("mc68020"); \ - } \ - while (0) - -#define TARGET_OBJFMT_CPP_BUILTINS() \ - do \ - { \ - builtin_define ("__ELF__"); \ - } \ - while (0) +#define TARGET_OS_CPP_BUILTINS() LINUX_TARGET_OS_CPP_BUILTINS() #undef CPP_SPEC #define CPP_SPEC "%{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT}" @@ -175,12 +149,6 @@ #define FUNCTION_PROFILER(FILE, LABELNO) fprintf (FILE, "\tjbsr _mcount\n"); \ } -/* How to renumber registers for dbx and gdb. - On the Sun-3, the floating point registers have numbers - 18 to 25, not 16 to 23 as they do in the compiler. */ - -#define DBX_REGISTER_NUMBER(REGNO) ((REGNO) < 16 ? (REGNO) : (REGNO) + 2) - /* Do not break .stabs pseudos into continuations. */ #define DBX_CONTIN_LENGTH 0 Index: gcc/config/m68k/netbsd-elf.h =================================================================== --- gcc/config/m68k/netbsd-elf.h 2007-01-09 15:01:56.000000000 +0000 +++ gcc/config/m68k/netbsd-elf.h 2007-01-09 15:02:00.000000000 +0000 @@ -134,12 +134,6 @@ #define LOCAL_LABEL_PREFIX "." #define USER_LABEL_PREFIX "" -/* The prefix for immediate operands. */ - -#undef IMMEDIATE_PREFIX -#define IMMEDIATE_PREFIX "#" - - #undef ASM_COMMENT_START #define ASM_COMMENT_START "|" @@ -329,12 +323,6 @@ #define EMPTY_FIELD_BOUNDARY 32 #define BIGGEST_ALIGNMENT 64 -/* For m68k SVR4, structures are returned using the reentrant - technique. */ - -#undef PCC_STATIC_STRUCT_RETURN - - /* The svr4 ABI for the m68k says that records and unions are returned in memory. */ Index: gcc/config/m68k/openbsd.h =================================================================== --- gcc/config/m68k/openbsd.h 2007-01-09 15:01:51.000000000 +0000 +++ gcc/config/m68k/openbsd.h 2007-01-09 15:02:00.000000000 +0000 @@ -73,6 +73,10 @@ #define DBX_CONTIN_CHAR '?' /* Stack & calling: aggregate returns. */ +/* ??? This is traditional, but quite possibly wrong. It appears to + disagree with gdb. */ +#define PCC_STATIC_STRUCT_RETURN 1 + /* Don't default to pcc-struct-return, because gcc is the only compiler, and we want to retain compatibility with older gcc versions. */ #define DEFAULT_PCC_STRUCT_RETURN 0 ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 19/63] Make MOTOROLA a numeric macro from the outset 2007-01-10 11:15 ` [ColdFire 18/63] Configuration cleanups Richard Sandiford @ 2007-01-10 11:16 ` Richard Sandiford 2007-01-10 11:17 ` [ColdFire 20/63] Factor out soft-float library support Richard Sandiford 2007-01-18 19:26 ` [ColdFire 19/63] Make MOTOROLA a numeric macro from the outset Richard Sandiford 2007-01-10 18:51 ` [ColdFire 18/63] Configuration cleanups Jeffrey Law 1 sibling, 2 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 11:16 UTC (permalink / raw) To: gcc-patches Just a small cleanup. config/m68k wants MOTOROLA to be a numeric macro, so this patch defines it that way from the outset. Richard gcc/ 200x-xx-xx Nathan Sidwell <nathan@codesourcery.com> * config.gcc (m68k-*-aout*, m68k-*-coff*, m68020-*-elf*, m68k-*-elf*) (m68010-*-netbsdelf*, m68k*-*-netbsdelf*, m68k*-*-openbsd*) (m68k-*-uclinux*, m68k-*-linux*, m68k-*-rtems*): Use tm_file rather than m68k/m68k.h and explicitly set MOTOROLA to 1. * config/m68k/m68k.h (MOTOROLA): Simplify definition accordingly. Index: gcc/config.gcc =================================================================== --- gcc/config.gcc 2007-01-09 15:01:59.000000000 +0000 +++ gcc/config.gcc 2007-01-09 15:02:02.000000000 +0000 @@ -1473,40 +1473,40 @@ m68hc12-*-*|m6812-*-*) m68k-*-aout*) default_m68k_cpu=68020 tmake_file=m68k/t-m68kbare - tm_file="m68k/m68k.h m68k/m68k-none.h m68k/m68kemb.h m68k/m68k-aout.h libgloss.h" + tm_file="${tm_file} m68k/m68k-none.h m68k/m68kemb.h m68k/m68k-aout.h libgloss.h" ;; m68k-*-coff*) default_m68k_cpu=68020 tmake_file=m68k/t-m68kbare - tm_defines="${tm_defines} MOTOROLA USE_GAS" - tm_file="m68k/m68k.h m68k/m68k-none.h m68k/m68kemb.h dbxcoff.h m68k/coff.h dbx.h" + tm_defines="${tm_defines} MOTOROLA=1 USE_GAS" + tm_file="${tm_file} m68k/m68k-none.h m68k/m68kemb.h dbxcoff.h m68k/coff.h dbx.h" use_fixproto=yes ;; m68020-*-elf* | m68k-*-elf*) default_m68k_cpu=68020 - tm_file="m68k/m68k.h m68k/m68k-none.h m68k/m68kelf.h dbxelf.h elfos.h m68k/m68kemb.h m68k/m68020-elf.h" - tm_defines="${tm_defines} MOTOROLA USE_GAS" + tm_file="${tm_file} m68k/m68k-none.h m68k/m68kelf.h dbxelf.h elfos.h m68k/m68kemb.h m68k/m68020-elf.h" + tm_defines="${tm_defines} MOTOROLA=1 USE_GAS" tmake_file=m68k/t-m68kelf extra_parts="crtbegin.o crtend.o" ;; m68010-*-netbsdelf* | m68k*-*-netbsdelf*) default_m68k_cpu=68020 tm_file="${tm_file} dbxelf.h elfos.h netbsd.h netbsd-elf.h m68k/netbsd-elf.h" - tm_defines="${tm_defines} MOTOROLA USE_GAS" + tm_defines="${tm_defines} MOTOROLA=1 USE_GAS" ;; m68k*-*-openbsd*) default_m68k_cpu=68020 # needed to unconfuse gdb tm_defines="${tm_defines} OBSD_OLD_GAS" - tm_file="m68k/m68k.h openbsd.h m68k/openbsd.h" + tm_file="${tm_file} openbsd.h m68k/openbsd.h" tmake_file="t-libc-ok t-openbsd m68k/t-openbsd" # we need collect2 until our bug is fixed... use_collect2=yes ;; m68k-*-uclinux*) # Motorola m68k/ColdFire running uClinux with uClibc default_m68k_cpu=68020 - tm_file="m68k/m68k.h dbxelf.h elfos.h svr4.h linux.h flat.h m68k/linux.h m68k/uclinux.h" - tm_defines="${tm_defines} MOTOROLA USE_GAS UCLIBC_DEFAULT=1" + tm_file="${tm_file} dbxelf.h elfos.h svr4.h linux.h flat.h m68k/linux.h m68k/uclinux.h" + tm_defines="${tm_defines} MOTOROLA=1 USE_GAS UCLIBC_DEFAULT=1" extra_options="${extra_options} linux.opt" tmake_file=m68k/t-uclinux use_fixproto=no @@ -1515,9 +1515,9 @@ m68k-*-linux*) # Motorola m68k's runnin # with ELF format using glibc 2 # aka the GNU/Linux C library 6. default_m68k_cpu=68020 - tm_file="m68k/m68k.h dbxelf.h elfos.h svr4.h linux.h m68k/linux.h" + tm_file="${tm_file} dbxelf.h elfos.h svr4.h linux.h m68k/linux.h" extra_options="${extra_options} m68k/ieee.opt" - tm_defines="${tm_defines} MOTOROLA USE_GAS" + tm_defines="${tm_defines} MOTOROLA=1 USE_GAS" # if not configured with --enable-sjlj-exceptions, bump the # libgcc version number if test x$sjlj != x1; then @@ -1527,8 +1527,8 @@ m68k-*-linux*) # Motorola m68k's runnin m68k-*-rtems*) default_m68k_cpu=68020 tmake_file="m68k/t-m68kbare m68k/t-crtstuff t-rtems m68k/t-rtems" - tm_file="m68k/m68k.h m68k/m68k-none.h m68k/m68kelf.h dbxelf.h elfos.h m68k/m68kemb.h m68k/m68020-elf.h m68k/rtemself.h rtems.h" - tm_defines="${tm_defines} MOTOROLA USE_GAS" + tm_file="${tm_file} m68k/m68k-none.h m68k/m68kelf.h dbxelf.h elfos.h m68k/m68kemb.h m68k/m68020-elf.h m68k/rtemself.h rtems.h" + tm_defines="${tm_defines} MOTOROLA=1 USE_GAS" extra_parts="crtbegin.o crtend.o" ;; mcore-*-elf) Index: gcc/config/m68k/m68k.h =================================================================== --- gcc/config/m68k/m68k.h 2007-01-09 15:02:00.000000000 +0000 +++ gcc/config/m68k/m68k.h 2007-01-09 15:02:02.000000000 +0000 @@ -23,13 +23,11 @@ the Free Software Foundation; either ver if-statements and ?: on it. This way we have compile-time error checking for both the MOTOROLA and MIT code paths. We do rely on the host compiler to optimize away all constant tests. */ -#ifdef MOTOROLA -# undef MOTOROLA -# define MOTOROLA 1 /* Use the Motorola assembly syntax. */ +#if MOTOROLA /* Use the Motorola assembly syntax. */ # define TARGET_VERSION fprintf (stderr, " (68k, Motorola syntax)") #else -# define TARGET_VERSION fprintf (stderr, " (68k, MIT syntax)") # define MOTOROLA 0 /* Use the MIT assembly syntax. */ +# define TARGET_VERSION fprintf (stderr, " (68k, MIT syntax)") #endif /* Handle --with-cpu default option from configure script. */ ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 20/63] Factor out soft-float library support 2007-01-10 11:16 ` [ColdFire 19/63] Make MOTOROLA a numeric macro from the outset Richard Sandiford @ 2007-01-10 11:17 ` Richard Sandiford 2007-01-10 11:19 ` [ColdFire 21/63] Add *_REGNO_P macros Richard Sandiford 2007-01-10 21:32 ` [ColdFire 20/63] Factor out soft-float library support Jeffrey Law 2007-01-18 19:26 ` [ColdFire 19/63] Make MOTOROLA a numeric macro from the outset Richard Sandiford 1 sibling, 2 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 11:17 UTC (permalink / raw) To: gcc-patches The soft-float makefile fragments are duplicated in several target files. This patch moves them to a common file called t-floatlib. It also prevents the XFmode patterns from being used on ColdFire targets, for which long double is now DFmode. Richard gcc/ 200x-xx-xx Nathan Sidwell <nathan@codesourcery.com> * config.gcc (m68k-*-aout*, m68k-*-coff*, m68020-*-elf*, m68k-*-elf*) (m68k-*-uclinux*, m68k-*-rtems*): Add t-floatlib to $tmake_file. * config/m68k/t-floatlib: New file, extracting common code from... * config/m68k/t-m68kbare, config/m68k/t-m68kelf, * config/m68k/t-uclinux: Here. * config/m68k/fpgnulib.c: Do not compile extendeed precision routines on ColdFire targets. Index: gcc/config.gcc =================================================================== --- gcc/config.gcc 2007-01-09 15:02:02.000000000 +0000 +++ gcc/config.gcc 2007-01-09 15:02:03.000000000 +0000 @@ -1472,12 +1472,12 @@ m68hc12-*-*|m6812-*-*) ;; m68k-*-aout*) default_m68k_cpu=68020 - tmake_file=m68k/t-m68kbare + tmake_file="m68k/t-floatlib m68k/t-m68kbare" tm_file="${tm_file} m68k/m68k-none.h m68k/m68kemb.h m68k/m68k-aout.h libgloss.h" ;; m68k-*-coff*) default_m68k_cpu=68020 - tmake_file=m68k/t-m68kbare + tmake_file="m68k/t-floatlib m68k/t-m68kbare" tm_defines="${tm_defines} MOTOROLA=1 USE_GAS" tm_file="${tm_file} m68k/m68k-none.h m68k/m68kemb.h dbxcoff.h m68k/coff.h dbx.h" use_fixproto=yes @@ -1486,7 +1486,7 @@ m68020-*-elf* | m68k-*-elf*) default_m68k_cpu=68020 tm_file="${tm_file} m68k/m68k-none.h m68k/m68kelf.h dbxelf.h elfos.h m68k/m68kemb.h m68k/m68020-elf.h" tm_defines="${tm_defines} MOTOROLA=1 USE_GAS" - tmake_file=m68k/t-m68kelf + tmake_file="m68k/t-floatlib m68k/t-m68kelf" extra_parts="crtbegin.o crtend.o" ;; m68010-*-netbsdelf* | m68k*-*-netbsdelf*) @@ -1508,7 +1508,7 @@ m68k-*-uclinux*) # Motorola m68k/ColdFi tm_file="${tm_file} dbxelf.h elfos.h svr4.h linux.h flat.h m68k/linux.h m68k/uclinux.h" tm_defines="${tm_defines} MOTOROLA=1 USE_GAS UCLIBC_DEFAULT=1" extra_options="${extra_options} linux.opt" - tmake_file=m68k/t-uclinux + tmake_file="m68k/t-floatlib m68k/t-uclinux" use_fixproto=no ;; m68k-*-linux*) # Motorola m68k's running GNU/Linux @@ -1526,7 +1526,7 @@ m68k-*-linux*) # Motorola m68k's runnin ;; m68k-*-rtems*) default_m68k_cpu=68020 - tmake_file="m68k/t-m68kbare m68k/t-crtstuff t-rtems m68k/t-rtems" + tmake_file="m68k/t-floatlib m68k/t-m68kbare m68k/t-crtstuff t-rtems m68k/t-rtems" tm_file="${tm_file} m68k/m68k-none.h m68k/m68kelf.h dbxelf.h elfos.h m68k/m68kemb.h m68k/m68020-elf.h m68k/rtemself.h rtems.h" tm_defines="${tm_defines} MOTOROLA=1 USE_GAS" extra_parts="crtbegin.o crtend.o" Index: gcc/config/m68k/t-floatlib =================================================================== --- /dev/null 2007-01-09 03:39:34.548096750 +0000 +++ gcc/config/m68k/t-floatlib 2007-01-09 15:02:03.000000000 +0000 @@ -0,0 +1,13 @@ +LIB1ASMSRC = m68k/lb1sf68.asm +LIB1ASMFUNCS = _mulsi3 _udivsi3 _divsi3 _umodsi3 _modsi3 \ + _double _float _floatex \ + _eqdf2 _nedf2 _gtdf2 _gedf2 _ltdf2 _ledf2 \ + _eqsf2 _nesf2 _gtsf2 _gesf2 _ltsf2 _lesf2 + +LIB2FUNCS_EXTRA = fpgnulib.c xfgnulib.c + +fpgnulib.c: $(srcdir)/config/m68k/fpgnulib.c + cp $(srcdir)/config/m68k/fpgnulib.c fpgnulib.c +xfgnulib.c: $(srcdir)/config/m68k/fpgnulib.c + echo '#define EXTFLOAT' > xfgnulib.c + cat $(srcdir)/config/m68k/fpgnulib.c >> xfgnulib.c Index: gcc/config/m68k/t-m68kbare =================================================================== --- gcc/config/m68k/t-m68kbare 2007-01-09 15:01:41.000000000 +0000 +++ gcc/config/m68k/t-m68kbare 2007-01-09 15:02:03.000000000 +0000 @@ -1,17 +1,3 @@ -LIB1ASMSRC = m68k/lb1sf68.asm -LIB1ASMFUNCS = _mulsi3 _udivsi3 _divsi3 _umodsi3 _modsi3 \ - _double _float _floatex \ - _eqdf2 _nedf2 _gtdf2 _gedf2 _ltdf2 _ledf2 \ - _eqsf2 _nesf2 _gtsf2 _gesf2 _ltsf2 _lesf2 - -LIB2FUNCS_EXTRA = fpgnulib.c xfgnulib.c - -fpgnulib.c: $(srcdir)/config/m68k/fpgnulib.c - cp $(srcdir)/config/m68k/fpgnulib.c fpgnulib.c -xfgnulib.c: $(srcdir)/config/m68k/fpgnulib.c - echo '#define EXTFLOAT' > xfgnulib.c - cat $(srcdir)/config/m68k/fpgnulib.c >> xfgnulib.c - MULTILIB_OPTIONS = m68000/m68020/m5200/mcpu32/m68040/m68060 m68881/msoft-float MULTILIB_DIRNAMES = MULTILIB_MATCHES = m68000=mc68000 m68000=m68302 mcpu32=m68332 m68020=mc68020 Index: gcc/config/m68k/t-m68kelf =================================================================== --- gcc/config/m68k/t-m68kelf 2007-01-09 15:01:41.000000000 +0000 +++ gcc/config/m68k/t-m68kelf 2007-01-09 15:02:03.000000000 +0000 @@ -1,17 +1,3 @@ -LIB1ASMSRC = m68k/lb1sf68.asm -LIB1ASMFUNCS = _mulsi3 _udivsi3 _divsi3 _umodsi3 _modsi3 \ - _double _float _floatex \ - _eqdf2 _nedf2 _gtdf2 _gedf2 _ltdf2 _ledf2 \ - _eqsf2 _nesf2 _gtsf2 _gesf2 _ltsf2 _lesf2 - -LIB2FUNCS_EXTRA = fpgnulib.c xfgnulib.c - -fpgnulib.c: $(srcdir)/config/m68k/fpgnulib.c - cp $(srcdir)/config/m68k/fpgnulib.c fpgnulib.c -xfgnulib.c: $(srcdir)/config/m68k/fpgnulib.c - echo '#define EXTFLOAT' > xfgnulib.c - cat $(srcdir)/config/m68k/fpgnulib.c >> xfgnulib.c - MULTILIB_OPTIONS = m68000/m68020/m5200/m5206e/m528x/m5307/m5407/mcfv4e/mcpu32/m68040/m68060 m68881/msoft-float MULTILIB_DIRNAMES = MULTILIB_MATCHES = m68000=mc68000 m68000=m68302 mcpu32=m68332 m68020=mc68020 m5206e=m5272 Index: gcc/config/m68k/t-uclinux =================================================================== --- gcc/config/m68k/t-uclinux 2007-01-09 15:01:59.000000000 +0000 +++ gcc/config/m68k/t-uclinux 2007-01-09 15:02:03.000000000 +0000 @@ -1,20 +1,6 @@ # crti and crtn are provided by uClibc. EXTRA_MULTILIB_PARTS=crtbegin.o crtend.o -LIB1ASMSRC = m68k/lb1sf68.asm -LIB1ASMFUNCS = _mulsi3 _udivsi3 _divsi3 _umodsi3 _modsi3 \ - _double _float _floatex \ - _eqdf2 _nedf2 _gtdf2 _gedf2 _ltdf2 _ledf2 \ - _eqsf2 _nesf2 _gtsf2 _gesf2 _ltsf2 _lesf2 - -LIB2FUNCS_EXTRA = fpgnulib.c xfgnulib.c - -fpgnulib.c: $(srcdir)/config/m68k/fpgnulib.c - cp $(srcdir)/config/m68k/fpgnulib.c fpgnulib.c -xfgnulib.c: $(srcdir)/config/m68k/fpgnulib.c - echo '#define EXTFLOAT' > xfgnulib.c - cat $(srcdir)/config/m68k/fpgnulib.c >> xfgnulib.c - MULTILIB_OPTIONS = m68000/m5200/m5206e/m528x/m5307/m5407/mcpu32 msep-data/mid-shared-library MULTILIB_DIRNAMES = MULTILIB_MATCHES = m68000=mc68000 m68000=m68302 mcpu32=m68332 m5206e=m5272 Index: gcc/config/m68k/fpgnulib.c =================================================================== --- gcc/config/m68k/fpgnulib.c 2007-01-09 15:01:41.000000000 +0000 +++ gcc/config/m68k/fpgnulib.c 2007-01-09 15:02:03.000000000 +0000 @@ -361,6 +361,10 @@ __fixsfsi (float a1) \f #else /* EXTFLOAT */ +/* We do not need these routines for coldfire, as it has no extended + float format. */ +#if !defined (__mcoldfire__) + /* Primitive extended precision floating point support. We assume all numbers are normalized, don't do any rounding, etc. */ @@ -569,4 +573,5 @@ __gexf2 (long double x1, long double x2) return __cmpdf2 ((double) x1, (double) x2); } +#endif /* !__mcoldfire__ */ #endif /* EXTFLOAT */ ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 21/63] Add *_REGNO_P macros 2007-01-10 11:17 ` [ColdFire 20/63] Factor out soft-float library support Richard Sandiford @ 2007-01-10 11:19 ` Richard Sandiford 2007-01-10 11:20 ` [ColdFire 22/63] Remove redundant PIC handling Richard Sandiford ` (2 more replies) 2007-01-10 21:32 ` [ColdFire 20/63] Factor out soft-float library support Jeffrey Law 1 sibling, 3 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 11:19 UTC (permalink / raw) To: gcc-patches The m68k port has cryptic conditions like: (REGNO (X) ^ 020) >= 8 (which checks whether something is not a hard floating-point register). This patch replaces them with more readable *_REGNO_P macros, which are then used by later patches in the series. The patch also replaces a hard-coded 8 with A0_REG. Richard gcc/ 200x-xx-xx Kazu Hirata <kazu@codesourcery.com> Richard Sandiford <richard@codesourcery.com> * config/m68k/m68k.h (DATA_REGNO_P, ADDRESS_REGNO_P, INT_REGNO_P) (FP_REGNO_P): New macros. (REGNO_OK_FOR_INDEX_P, REGNO_OK_FOR_BASE_P, REGNO_OK_FOR_DATA_P) (REGNO_OK_FOR_FP_P, REG_OK_FOR_INDEX_P, REG_OK_FOR_BASE_P): Use them. (EH_RETURN_STACKADJ_RTX): Use A0_REG. * config/m68k/m68k.c (m68k_regno_mode_ok): Use the new REGNO macros. Index: gcc/config/m68k/m68k.h =================================================================== --- gcc/config/m68k/m68k.h 2007-01-09 15:02:02.000000000 +0000 +++ gcc/config/m68k/m68k.h 2007-01-09 15:02:04.000000000 +0000 @@ -741,14 +741,33 @@ #define HAVE_PRE_DECREMENT 1 /* Macros to check register numbers against specific register classes. */ -#define REGNO_OK_FOR_INDEX_P(REGNO) \ -((REGNO) < 16 || (unsigned) reg_renumber[REGNO] < 16) -#define REGNO_OK_FOR_BASE_P(REGNO) \ -(((REGNO) ^ 010) < 8 || (unsigned) (reg_renumber[REGNO] ^ 010) < 8) -#define REGNO_OK_FOR_DATA_P(REGNO) \ -((REGNO) < 8 || (unsigned) reg_renumber[REGNO] < 8) -#define REGNO_OK_FOR_FP_P(REGNO) \ -(((REGNO) ^ 020) < 8 || (unsigned) (reg_renumber[REGNO] ^ 020) < 8) +/* True for data registers, D0 through D7. */ +#define DATA_REGNO_P(REGNO) ((unsigned int) (REGNO) < 8) + +/* True for address registers, A0 through A7. */ +#define ADDRESS_REGNO_P(REGNO) (((unsigned int) (REGNO) - 8) < 8) + +/* True for integer registers, D0 through D7 and A0 through A7. */ +#define INT_REGNO_P(REGNO) ((unsigned int) (REGNO) < 16) + +/* True for floating point registers, FP0 through FP7. */ +#define FP_REGNO_P(REGNO) (((unsigned int) (REGNO) - 16) < 8) + +#define REGNO_OK_FOR_INDEX_P(REGNO) \ + (INT_REGNO_P (REGNO) \ + || INT_REGNO_P (reg_renumber[REGNO])) + +#define REGNO_OK_FOR_BASE_P(REGNO) \ + (ADDRESS_REGNO_P (REGNO) \ + || ADDRESS_REGNO_P (reg_renumber[REGNO])) + +#define REGNO_OK_FOR_DATA_P(REGNO) \ + (DATA_REGNO_P (REGNO) \ + || DATA_REGNO_P (reg_renumber[REGNO])) + +#define REGNO_OK_FOR_FP_P(REGNO) \ + (FP_REGNO_P (REGNO) \ + || FP_REGNO_P (reg_renumber[REGNO])) /* Now macros that check whether X is a register and also, strictly, whether it is in a specified class. @@ -801,10 +820,11 @@ #define LEGITIMATE_PIC_OPERAND_P(X) \ /* Nonzero if X is a hard reg that can be used as an index or if it is a pseudo reg. */ -#define REG_OK_FOR_INDEX_P(X) ((REGNO (X) ^ 020) >= 8) +#define REG_OK_FOR_INDEX_P(X) !FP_REGNO_P (REGNO (X)) /* Nonzero if X is a hard reg that can be used as a base reg or if it is a pseudo reg. */ -#define REG_OK_FOR_BASE_P(X) ((REGNO (X) & ~027) != 0) +#define REG_OK_FOR_BASE_P(X) \ + (!DATA_REGNO_P (REGNO (X)) && !FP_REGNO_P (REGNO (X))) #else @@ -1085,7 +1105,7 @@ #define INCOMING_FRAME_SP_OFFSET 4 /* Describe how we implement __builtin_eh_return. */ #define EH_RETURN_DATA_REGNO(N) \ ((N) < 2 ? (N) : INVALID_REGNUM) -#define EH_RETURN_STACKADJ_RTX gen_rtx_REG (Pmode, 8) +#define EH_RETURN_STACKADJ_RTX gen_rtx_REG (Pmode, A0_REG) #define EH_RETURN_HANDLER_RTX \ gen_rtx_MEM (Pmode, \ gen_rtx_PLUS (Pmode, arg_pointer_rtx, \ Index: gcc/config/m68k/m68k.c =================================================================== --- gcc/config/m68k/m68k.c 2007-01-09 15:01:59.000000000 +0000 +++ gcc/config/m68k/m68k.c 2007-01-09 15:02:04.000000000 +0000 @@ -3852,13 +3852,13 @@ m68k_hard_regno_rename_ok (unsigned int bool m68k_regno_mode_ok (int regno, enum machine_mode mode) { - if (regno < 8) + if (DATA_REGNO_P (regno)) { /* Data Registers, can hold aggregate if fits in. */ if (regno + GET_MODE_SIZE (mode) / 4 <= 8) return true; } - else if (regno < 16) + else if (ADDRESS_REGNO_P (regno)) { /* Address Registers, can't hold bytes, can hold aggregate if fits in. */ @@ -3867,7 +3867,7 @@ m68k_regno_mode_ok (int regno, enum mach if (regno + GET_MODE_SIZE (mode) / 4 <= 16) return true; } - else if (regno < 24) + else if (FP_REGNO_P (regno)) { /* FPU registers, hold float or complex float of long double or smaller. */ ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 22/63] Remove redundant PIC handling 2007-01-10 11:19 ` [ColdFire 21/63] Add *_REGNO_P macros Richard Sandiford @ 2007-01-10 11:20 ` Richard Sandiford 2007-01-10 11:21 ` [ColdFire 23/63] Some assorted cleanups Richard Sandiford 2007-01-10 18:41 ` [ColdFire 22/63] Remove redundant PIC handling Jeffrey Law 2007-01-10 17:55 ` [ColdFire 21/63] Add *_REGNO_P macros Jeffrey Law 2007-01-15 18:51 ` Roman Zippel 2 siblings, 2 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 11:20 UTC (permalink / raw) To: gcc-patches The comment for cmpsi claims that it too needs to handle illegitimate constant operands, in much the same way as movsi does. This may have been true in the old days, but I don't think it is now. This patch removes the comment and associated code. Note that the comment above movsi doesn't need any adjusting; it doesn't refer to cmpsi. The patch also adds a PIC testcase that failed at one stage during the original development process. Richard gcc/ * config/m68k/m68k.md (cmpsi): Remove outdated flag_pic handling. gcc/testsuite/ 200x-xx-xx Nathan Sidwell <nathan@codesourcery.com> * gcc.dg/m68k-pic-1.c: New. Index: gcc/config/m68k/m68k.md =================================================================== --- gcc/config/m68k/m68k.md 2007-01-09 15:01:56.000000000 +0000 +++ gcc/config/m68k/m68k.md 2007-01-09 15:02:04.000000000 +0000 @@ -308,8 +308,6 @@ (define_insn "" } }) -;; This is the second "hook" for PIC code (in addition to movsi). See -;; comment of movsi for a description of PIC handling. (define_expand "cmpsi" [(set (cc0) (compare (match_operand:SI 0 "nonimmediate_operand" "") @@ -317,15 +315,6 @@ (define_expand "cmpsi" "" { m68k_last_compare_had_fp_operands = 0; - if (flag_pic && !TARGET_PCREL && symbolic_operand (operands[1], SImode)) - { - /* The source is an address which requires PIC relocation. - Call legitimize_pic_address with the source, mode, and a relocation - register (a new pseudo, or the final destination if reload_in_progress - is set). Then fall through normally */ - rtx temp = reload_in_progress ? operands[0] : gen_reg_rtx (Pmode); - operands[1] = legitimize_pic_address (operands[1], SImode, temp); - } }) ;; A composite of the cmp, cmpa, cmpi & cmpm m68000 op codes. Index: gcc/testsuite/gcc.dg/m68k-pic-1.c =================================================================== --- /dev/null 2007-01-09 03:39:34.548096750 +0000 +++ gcc/testsuite/gcc.dg/m68k-pic-1.c 2007-01-09 15:02:04.000000000 +0000 @@ -0,0 +1,18 @@ +/* { dg-do compile { target m68k-*-* } } */ +/* { dg-options "-O2 -fpic" } */ + +extern void Foo (void *); + +char *ary[] = {"a", "b", "c", "d", "e"}; + +void Bar (void) +{ + int cnt = 0; + + for (cnt = 0; cnt < 4; ++cnt) + { + char *ptr = ary[cnt]; + + Foo (&ptr); + } +} ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 23/63] Some assorted cleanups 2007-01-10 11:20 ` [ColdFire 22/63] Remove redundant PIC handling Richard Sandiford @ 2007-01-10 11:21 ` Richard Sandiford 2007-01-10 11:23 ` [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro Richard Sandiford 2007-01-10 18:43 ` [ColdFire 23/63] Some assorted cleanups Jeffrey Law 2007-01-10 18:41 ` [ColdFire 22/63] Remove redundant PIC handling Jeffrey Law 1 sibling, 2 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 11:21 UTC (permalink / raw) To: gcc-patches A few assorted, minor cleanups. Richard gcc/ 200x-xx-xx Nathan Sidwell <nathan@codesourcery.com> * config/m68k/m68k.h (REGISTER_MOVE_COST): Simplify definition. (STACK_GROWS_DOWNWARD): Define to 1. (FUNCTION_VALUE, LIBCALL_VALUE, FUNCTION_VALUE_REGNO_P): Equivocate comments, emphasizing that these values are only defaults. * config/m68k/linux.h (LINK_SPEC): Fix formatting in #undef. * config/m68k/m68k.c (const_method): Remove trailing whitespace. Index: gcc/config/m68k/m68k.h =================================================================== --- gcc/config/m68k/m68k.h 2007-01-09 15:02:04.000000000 +0000 +++ gcc/config/m68k/m68k.h 2007-01-09 15:02:05.000000000 +0000 @@ -577,13 +577,11 @@ #define CLASS_MAX_NREGS(CLASS, MODE) \ /* Moves between fp regs and other regs are two insns. */ #define REGISTER_MOVE_COST(MODE, CLASS1, CLASS2) \ - (((CLASS1) == FP_REGS && (CLASS2) != FP_REGS) \ - || ((CLASS2) == FP_REGS && (CLASS1) != FP_REGS) \ - ? 4 : 2) + ((((CLASS1) == FP_REGS) != ((CLASS2) == FP_REGS)) ? 4 : 2) \f /* Stack layout; function entry, exit and calling. */ -#define STACK_GROWS_DOWNWARD +#define STACK_GROWS_DOWNWARD 1 #define FRAME_GROWS_DOWNWARD 1 #define STARTING_FRAME_OFFSET 0 @@ -608,14 +606,14 @@ #define RETURN_POPS_ARGS(FUNDECL,FUNTYPE == void_type_node))) \ ? (SIZE) : 0) -/* On the m68k the return value is always in D0. */ +/* On the m68k the return value defaults to D0. */ #define FUNCTION_VALUE(VALTYPE, FUNC) \ gen_rtx_REG (TYPE_MODE (VALTYPE), 0) -/* On the m68k the return value is always in D0. */ +/* On the m68k the return value defaults to D0. */ #define LIBCALL_VALUE(MODE) gen_rtx_REG (MODE, 0) -/* On the m68k, D0 is the only register used. */ +/* On the m68k, D0 is usually the only register used. */ #define FUNCTION_VALUE_REGNO_P(N) ((N) == 0) /* Define this to be true when FUNCTION_VALUE_REGNO_P is true for Index: gcc/config/m68k/linux.h =================================================================== --- gcc/config/m68k/linux.h 2007-01-09 15:02:00.000000000 +0000 +++ gcc/config/m68k/linux.h 2007-01-09 15:02:05.000000000 +0000 @@ -82,7 +82,7 @@ #define CPP_SPEC "%{posix:-D_POSIX_SOURC #define GLIBC_DYNAMIC_LINKER "/lib/ld.so.1" -#undef LINK_SPEC +#undef LINK_SPEC #define LINK_SPEC "-m m68kelf %{shared} \ %{!shared: \ %{!static: \ Index: gcc/config/m68k/m68k.c =================================================================== --- gcc/config/m68k/m68k.c 2007-01-09 15:02:04.000000000 +0000 +++ gcc/config/m68k/m68k.c 2007-01-09 15:02:05.000000000 +0000 @@ -1774,7 +1774,7 @@ const_method (rtx constant) /* The ColdFire doesn't have byte or word operations. */ /* FIXME: This may not be useful for the m68060 either. */ - if (!TARGET_COLDFIRE) + if (!TARGET_COLDFIRE) { /* if -256 < N < 256 but N is not in range for a moveq N^ff will be, so use moveq #N^ff, dreg; not.b dreg. */ ^ permalink raw reply [flat|nested] 280+ messages in thread
* [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-01-10 11:21 ` [ColdFire 23/63] Some assorted cleanups Richard Sandiford @ 2007-01-10 11:23 ` Richard Sandiford 2007-01-10 11:24 ` [ColdFire 25/63] Define MODE_INDEX_REG_CLASS for m68k Richard Sandiford ` (2 more replies) 2007-01-10 18:43 ` [ColdFire 23/63] Some assorted cleanups Jeffrey Law 1 sibling, 3 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 11:23 UTC (permalink / raw) To: gcc-patches; +Cc: mark At the moment, gcc expects there to be a single INDEX_REG_CLASS that applies to all MEM modes. This is not true when using a ColdFire FPU, as index registers are not allowed for floating-point modes. The port tries to hack around this by using "<Q>U" instead of "m" in the movsf constraints, but that's only a half solution. If reload has to reload an indexed MEM (rather than the MEM's address), it will expect that instruction to match. The fix is to allow the class of index register to vary depending on the mode of the addressed value, as the base register class already can. This patch does the target-independent bit. It adds new target macros called MODE_INDEX_REG_CLASS and REGNO_MODE_OK_FOR_INDEX_P, to accompany the existing MODE_BASE_REG_CLASS and REGNO_MODE_OK_FOR_BASE_P. It also defines index equivalents of the addresses.h base functions. This is all a direct image of the base register code (including the wording of comments and documentation). I think the two should be consistent. The patch then adjusts all code to use thse new addresses.h functions. Bootstrapped & regression-tested on x86_64-linux-gnu. Richard gcc/ * Makefile.in (postreload.o): Depend on addresses.h. * addresses.h (index_reg_class, ok_for_index_p_1): New functions. (regno_ok_for_index_p): New function. * postreload.c: Include addresses.h. (reload_combine): Use index_reg_class instead of INDEX_REG_CLASS. * regclass.c (ok_for_index_p_nonstrict): Add a mode argument. Use ok_for_index_p_1 instead of REGNO_OK_FOR_INDEX_P. (record_address_regs): Use index_reg_class instead of INDEX_REG_CLASS. Update calls to ok_for_index_p_nonstrict. * regrename.c (scan_rtx_address): Use regno_ok_for_index_p instead of REGNO_OK_FOR_INDEX_P and index_reg_class instead of INDEX_REG_CLASS. (replace_oldest_value_addr): Likewise. * reload.c (find_reloads_address): Use index_reg_class instead of INDEX_REG_CLASS. Do not push an index register reload if index_reg_class returns NO_REGS. (find_reloads_address_1): Use index_reg_class instead of INDEX_REG_CLASS and regno_ok_for_index_p instead of REGNO_OK_FOR_INDEX_P. * doc/tm.texi (MODE_INDEX_REG_CLASS): Document new macro. (REGNO_MODE_OK_FOR_INDEX_P): Likewise. Index: gcc/Makefile.in =================================================================== --- gcc/Makefile.in 2007-01-09 15:01:56.000000000 +0000 +++ gcc/Makefile.in 2007-01-09 15:02:06.000000000 +0000 @@ -2532,7 +2532,7 @@ postreload.o : postreload.c $(CONFIG_H) $(RTL_H) $(REAL_H) $(FLAGS_H) $(EXPR_H) $(OPTABS_H) reload.h $(REGS_H) \ hard-reg-set.h insn-config.h $(BASIC_BLOCK_H) $(RECOG_H) output.h \ $(FUNCTION_H) toplev.h cselib.h $(TM_P_H) except.h $(TREE_H) $(MACHMODE_H) \ - $(OBSTACK_H) $(TIMEVAR_H) tree-pass.h + $(OBSTACK_H) $(TIMEVAR_H) tree-pass.h addresses.h postreload-gcse.o : postreload-gcse.c $(CONFIG_H) $(SYSTEM_H) coretypes.h \ $(TM_H) $(RTL_H) $(REGS_H) hard-reg-set.h $(FLAGS_H) insn-config.h \ $(RECOG_H) $(EXPR_H) $(BASIC_BLOCK_H) $(FUNCTION_H) output.h toplev.h \ Index: gcc/addresses.h =================================================================== --- gcc/addresses.h 2007-01-09 15:01:41.000000000 +0000 +++ gcc/addresses.h 2007-01-09 15:02:06.000000000 +0000 @@ -79,3 +79,42 @@ regno_ok_for_base_p (unsigned regno, enu return ok_for_base_p_1 (regno, mode, outer_code, index_code); } + +/* Wrapper function to unify target macros MODE_INDEX_REG_CLASS and + INDEX_REG_CLASS. Arguments as for the MODE_INDEX_REG_CLASS macro. */ + +static inline enum reg_class +index_reg_class (enum machine_mode mode ATTRIBUTE_UNUSED) +{ +#ifdef MODE_INDEX_REG_CLASS + return MODE_INDEX_REG_CLASS (mode); +#else + return INDEX_REG_CLASS; +#endif +} + +/* Wrapper function to unify target macros REGNO_MODE_OK_FOR_INDEX_P + and REGNO_OK_FOR_INDEX_P. Arguments as for the + REGNO_MODE_OK_FOR_INDEX_P macro. */ + +static inline bool +ok_for_index_p_1 (unsigned regno, enum machine_mode mode ATTRIBUTE_UNUSED) +{ +#ifdef REGNO_MODE_OK_FOR_INDEX_P + return REGNO_MODE_OK_FOR_INDEX_P (regno, mode); +#else + return REGNO_OK_FOR_INDEX_P (regno); +#endif +} + +/* Wrapper around ok_for_index_p_1, for use after register allocation is + complete. Arguments as for the called function. */ + +static inline bool +regno_ok_for_index_p (unsigned regno, enum machine_mode mode) +{ + if (regno >= FIRST_PSEUDO_REGISTER && reg_renumber[regno] >= 0) + regno = reg_renumber[regno]; + + return ok_for_index_p_1 (regno, mode); +} Index: gcc/postreload.c =================================================================== --- gcc/postreload.c 2007-01-09 15:01:41.000000000 +0000 +++ gcc/postreload.c 2007-01-09 15:02:06.000000000 +0000 @@ -46,6 +46,7 @@ Software Foundation; either version 2, o #include "tree.h" #include "timevar.h" #include "tree-pass.h" +#include "addresses.h" static int reload_cse_noop_set_p (rtx); static void reload_cse_simplify (rtx, rtx); @@ -703,17 +704,19 @@ reload_combine (void) int last_label_ruid; int min_labelno, n_labels; HARD_REG_SET ever_live_at_start, *label_live; + enum reg_class index_regs; /* If reg+reg can be used in offsetable memory addresses, the main chunk of reload has already used it where appropriate, so there is no use in trying to generate it now. */ - if (double_reg_address_ok && INDEX_REG_CLASS != NO_REGS) + index_regs = index_reg_class (VOIDmode); + if (double_reg_address_ok && index_regs != NO_REGS) return; /* To avoid wasting too much time later searching for an index register, determine the minimum and maximum index register numbers. */ for (r = 0; r < FIRST_PSEUDO_REGISTER; r++) - if (TEST_HARD_REG_BIT (reg_class_contents[INDEX_REG_CLASS], r)) + if (TEST_HARD_REG_BIT (reg_class_contents[index_regs], r)) { if (first_index_reg == -1) first_index_reg = r; @@ -822,8 +825,8 @@ reload_combine (void) substitute uses of REG (typically in MEMs) with. First check REG and BASE for being index registers; we can use them even if they are not dead. */ - if (TEST_HARD_REG_BIT (reg_class_contents[INDEX_REG_CLASS], regno) - || TEST_HARD_REG_BIT (reg_class_contents[INDEX_REG_CLASS], + if (TEST_HARD_REG_BIT (reg_class_contents[index_regs], regno) + || TEST_HARD_REG_BIT (reg_class_contents[index_regs], REGNO (base))) { const_reg = reg; @@ -837,8 +840,7 @@ reload_combine (void) two registers. */ for (i = first_index_reg; i <= last_index_reg; i++) { - if (TEST_HARD_REG_BIT (reg_class_contents[INDEX_REG_CLASS], - i) + if (TEST_HARD_REG_BIT (reg_class_contents[index_regs], i) && reg_state[i].use_index == RELOAD_COMBINE_MAX_USES && reg_state[i].store_ruid <= reg_state[regno].use_ruid && hard_regno_nregs[i][GET_MODE (reg)] == 1) Index: gcc/regclass.c =================================================================== --- gcc/regclass.c 2007-01-09 15:01:41.000000000 +0000 +++ gcc/regclass.c 2007-01-09 15:02:06.000000000 +0000 @@ -864,10 +864,10 @@ static void reg_scan_mark_refs (rtx, rtx /* Wrapper around REGNO_OK_FOR_INDEX_P, to allow pseudo registers. */ static inline bool -ok_for_index_p_nonstrict (rtx reg) +ok_for_index_p_nonstrict (rtx reg, enum machine_mode mode) { unsigned regno = REGNO (reg); - return regno >= FIRST_PSEUDO_REGISTER || REGNO_OK_FOR_INDEX_P (regno); + return regno >= FIRST_PSEUDO_REGISTER || ok_for_index_p_1 (regno, mode); } /* A version of regno_ok_for_base_p for use during regclass, when all pseudos @@ -1946,7 +1946,7 @@ record_address_regs (enum machine_mode m enum reg_class class; if (context == 1) - class = INDEX_REG_CLASS; + class = index_reg_class (mode); else class = base_reg_class (mode, outer_code, index_code); @@ -1996,7 +1996,8 @@ record_address_regs (enum machine_mode m as well as in the tests below, that all addresses are in canonical form. */ - else if (INDEX_REG_CLASS == base_reg_class (VOIDmode, PLUS, SCRATCH)) + else if (index_reg_class (mode) + == base_reg_class (mode, PLUS, SCRATCH)) { record_address_regs (mode, arg0, context, PLUS, code1, scale); if (! CONSTANT_P (arg1)) @@ -2022,7 +2023,7 @@ record_address_regs (enum machine_mode m else if (code0 == REG && code1 == REG && REGNO (arg0) < FIRST_PSEUDO_REGISTER && (ok_for_base_p_nonstrict (arg0, mode, PLUS, REG) - || ok_for_index_p_nonstrict (arg0))) + || ok_for_index_p_nonstrict (arg0, mode))) record_address_regs (mode, arg1, ok_for_base_p_nonstrict (arg0, mode, PLUS, REG) ? 1 : 0, @@ -2030,7 +2031,7 @@ record_address_regs (enum machine_mode m else if (code0 == REG && code1 == REG && REGNO (arg1) < FIRST_PSEUDO_REGISTER && (ok_for_base_p_nonstrict (arg1, mode, PLUS, REG) - || ok_for_index_p_nonstrict (arg1))) + || ok_for_index_p_nonstrict (arg1, mode))) record_address_regs (mode, arg0, ok_for_base_p_nonstrict (arg1, mode, PLUS, REG) ? 1 : 0, Index: gcc/regrename.c =================================================================== --- gcc/regrename.c 2007-01-09 15:01:41.000000000 +0000 +++ gcc/regrename.c 2007-01-09 15:02:06.000000000 +0000 @@ -574,17 +574,17 @@ scan_rtx_address (rtx insn, rtx *loc, en int index_op; unsigned regno0 = REGNO (op0), regno1 = REGNO (op1); - if (REGNO_OK_FOR_INDEX_P (regno0) + if (regno_ok_for_index_p (regno0, mode) && regno_ok_for_base_p (regno1, mode, PLUS, REG)) index_op = 0; - else if (REGNO_OK_FOR_INDEX_P (regno1) + else if (regno_ok_for_index_p (regno1, mode) && regno_ok_for_base_p (regno0, mode, PLUS, REG)) index_op = 1; else if (regno_ok_for_base_p (regno1, mode, PLUS, REG)) index_op = 0; else if (regno_ok_for_base_p (regno0, mode, PLUS, REG)) index_op = 1; - else if (REGNO_OK_FOR_INDEX_P (regno1)) + else if (regno_ok_for_index_p (regno1, mode)) index_op = 1; else index_op = 0; @@ -607,7 +607,7 @@ scan_rtx_address (rtx insn, rtx *loc, en } if (locI) - scan_rtx_address (insn, locI, INDEX_REG_CLASS, action, mode); + scan_rtx_address (insn, locI, index_reg_class (mode), action, mode); if (locB) scan_rtx_address (insn, locB, base_reg_class (mode, PLUS, index_code), action, mode); @@ -1498,17 +1498,17 @@ replace_oldest_value_addr (rtx *loc, enu int index_op; unsigned regno0 = REGNO (op0), regno1 = REGNO (op1); - if (REGNO_OK_FOR_INDEX_P (regno0) + if (regno_ok_for_index_p (regno0, mode) && regno_ok_for_base_p (regno1, mode, PLUS, REG)) index_op = 0; - else if (REGNO_OK_FOR_INDEX_P (regno1) + else if (regno_ok_for_index_p (regno1, mode) && regno_ok_for_base_p (regno0, mode, PLUS, REG)) index_op = 1; else if (regno_ok_for_base_p (regno1, mode, PLUS, REG)) index_op = 0; else if (regno_ok_for_base_p (regno0, mode, PLUS, REG)) index_op = 1; - else if (REGNO_OK_FOR_INDEX_P (regno1)) + else if (regno_ok_for_index_p (regno1, mode)) index_op = 1; else index_op = 0; @@ -1531,8 +1531,8 @@ replace_oldest_value_addr (rtx *loc, enu } if (locI) - changed |= replace_oldest_value_addr (locI, INDEX_REG_CLASS, mode, - insn, vd); + changed |= replace_oldest_value_addr (locI, index_reg_class (mode), + mode, insn, vd); if (locB) changed |= replace_oldest_value_addr (locB, base_reg_class (mode, PLUS, Index: gcc/reload.c =================================================================== --- gcc/reload.c 2007-01-09 15:01:41.000000000 +0000 +++ gcc/reload.c 2007-01-09 15:02:06.000000000 +0000 @@ -4965,7 +4965,7 @@ find_reloads_address (enum machine_mode loc = &XEXP (*loc, 0); } - if (double_reg_address_ok) + if (double_reg_address_ok && index_reg_class (mode) != NO_REGS) { /* Unshare the sum as well. */ *loc = ad = copy_rtx (ad); @@ -4973,8 +4973,8 @@ find_reloads_address (enum machine_mode /* Reload the displacement into an index reg. We assume the frame pointer or arg pointer is a base reg. */ find_reloads_address_part (XEXP (ad, 1), &XEXP (ad, 1), - INDEX_REG_CLASS, GET_MODE (ad), opnum, - type, ind_levels); + index_reg_class (mode), GET_MODE (ad), + opnum, type, ind_levels); return 0; } else @@ -5366,13 +5366,13 @@ find_reloads_address_1 (enum machine_mod #define REG_OK_FOR_CONTEXT(CONTEXT, REGNO, MODE, OUTER, INDEX) \ ((CONTEXT) == 0 \ ? regno_ok_for_base_p (REGNO, MODE, OUTER, INDEX) \ - : REGNO_OK_FOR_INDEX_P (REGNO)) + : regno_ok_for_index_p (REGNO, MODE)) enum reg_class context_reg_class; RTX_CODE code = GET_CODE (x); if (context == 1) - context_reg_class = INDEX_REG_CLASS; + context_reg_class = index_reg_class (mode); else context_reg_class = base_reg_class (mode, outer_code, index_code); @@ -5464,10 +5464,10 @@ #define REG_OK_FOR_CONTEXT(CONTEXT, REGN else if (code0 == REG && code1 == REG) { - if (REGNO_OK_FOR_INDEX_P (REGNO (op0)) + if (regno_ok_for_index_p (REGNO (op0), mode) && regno_ok_for_base_p (REGNO (op1), mode, PLUS, REG)) return 0; - else if (REGNO_OK_FOR_INDEX_P (REGNO (op1)) + else if (regno_ok_for_index_p (REGNO (op1), mode) && regno_ok_for_base_p (REGNO (op0), mode, PLUS, REG)) return 0; else if (regno_ok_for_base_p (REGNO (op1), mode, PLUS, REG)) @@ -5478,11 +5478,11 @@ #define REG_OK_FOR_CONTEXT(CONTEXT, REGN find_reloads_address_1 (mode, orig_op1, 1, PLUS, SCRATCH, &XEXP (x, 1), opnum, type, ind_levels, insn); - else if (REGNO_OK_FOR_INDEX_P (REGNO (op1))) + else if (regno_ok_for_index_p (REGNO (op1), mode)) find_reloads_address_1 (mode, orig_op0, 0, PLUS, REG, &XEXP (x, 0), opnum, type, ind_levels, insn); - else if (REGNO_OK_FOR_INDEX_P (REGNO (op0))) + else if (regno_ok_for_index_p (REGNO (op0), mode)) find_reloads_address_1 (mode, orig_op1, 0, PLUS, REG, &XEXP (x, 1), opnum, type, ind_levels, insn); @@ -5549,7 +5549,7 @@ #define REG_OK_FOR_CONTEXT(CONTEXT, REGN need to live longer than a TYPE reload normally would, so be conservative and class it as RELOAD_OTHER. */ if (REG_P (XEXP (op1, 1))) - if (!REGNO_OK_FOR_INDEX_P (REGNO (XEXP (op1, 1)))) + if (!regno_ok_for_index_p (REGNO (XEXP (op1, 1)), mode)) find_reloads_address_1 (mode, XEXP (op1, 1), 1, code, SCRATCH, &XEXP (op1, 1), opnum, RELOAD_OTHER, ind_levels, insn); Index: gcc/doc/tm.texi =================================================================== --- gcc/doc/tm.texi 2007-01-09 15:01:41.000000000 +0000 +++ gcc/doc/tm.texi 2007-01-09 15:02:06.000000000 +0000 @@ -2352,6 +2352,15 @@ address where its value is either multip added to another register (as well as added to a displacement). @end defmac +@defmac MODE_INDEX_REG_CLASS (@var{mode}) +This is a variation of the @code{INDEX_REG_CLASS} macro which allows +the selection of an index register in a mode dependent manner. It can +return @code{NO_REGS} for modes that do not support any form of index +register. If @var{mode} is @code{VOIDmode} then the macro should +return a class of registers that is suitable for all addresses in +which an index register of some form is allowed. +@end defmac + @defmac REGNO_OK_FOR_BASE_P (@var{num}) A C expression which is nonzero if register number @var{num} is suitable for use as a base register in operand addresses. It may be @@ -2409,6 +2418,14 @@ looking for one that is valid, and will only if neither labeling works. @end defmac +@defmac REGNO_MODE_OK_FOR_INDEX_P (@var{num}, @var{mode}) +A C expression that is just like @code{REGNO_OK_FOR_INDEX_P}, except +that the expression may examine the mode of the memory reference +in @var{mode}. If @var{mode} is @code{VOIDmode}, the macro should +return true if @var{x} is suitable for all modes in which some +form of index register is allowed. +@end defmac + @defmac PREFERRED_RELOAD_CLASS (@var{x}, @var{class}) A C expression that places additional restrictions on the register class to use when it is necessary to copy value @var{x} into a register in class ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 25/63] Define MODE_INDEX_REG_CLASS for m68k 2007-01-10 11:23 ` [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro Richard Sandiford @ 2007-01-10 11:24 ` Richard Sandiford 2007-01-10 11:28 ` [ColdFire 26/63] Rework the call and jump handling Richard Sandiford 2007-01-10 19:30 ` [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro Jeffrey Law 2007-01-12 15:45 ` Ian Lance Taylor 2 siblings, 1 reply; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 11:24 UTC (permalink / raw) To: gcc-patches This is the target-specific part of the index register patch. It defines the new MODE_INDEX_REG_CLASS and REGNO_MODE_OK_FOR_INDEX_P macros. It also uses "m" instead of "<Q>U" in the TARGET_COLDFIRE_FPU floating-point MEM constraints. Richard gcc/ * config/m68k/m68k.h (INDEX_REG_CLASS): Delete in favor of... (MODE_INDEX_REG_CLASS): ...this new macro. Return NO_REGS unless MODE_OK_FOR_INDEX_P. (MODE_OK_FOR_INDEX_P): New macro. (REGNO_OK_FOR_INDEX_P): Delete in favor of... (REGNO_MODE_OK_FOR_INDEX_P): ...this new macro. Return false unless MODE_OK_FOR_INDEX_P. (REG_OK_FOR_INDEX_P): Delete in favor of... (REG_MODE_OK_FOR_INDEX_P): ...this new macro. Return false unless MODE_OK_FOR_INDEX_P. (GO_IF_INDEXING): Add a mode argument and pass it on to LEGITIMATE_INDEX_P. (GO_IF_INDEXED_ADDRESS): Add a mode argument and pass it on to GO_IF_INDEXING. (LEGITIMATE_INDEX_REG_P): Add a mode argument. Use REG_MODE_OK_FOR_INDEX_P instead of REG_OK_FOR_INDEX_P. (LEGITIMATE_INDEX_P): Add a mode argument and pass it on to LEGITIMATE_INDEX_REG_P. (GO_IF_LEGITIMATE_ADDRESS): Update calls to GO_IF_INDEXED_ADDRESS and LEGITIMATE_INDEX_P. * config/m68k/m68k.md (tst<mode>_cf, cmp<mode>_cf, movsf_cf_hard) (movdf_cf_hard, extendsfdf2_cf, truncdfsf2_cf, ftrunc<mode>2_cf) (add<mode>3_cf, sub<mode>3_cf, fmul<mode>3_cf, div<mode>3_cf) (neg<mode>2_cf, sqrt<mode>2_cf, abs<mode>2_cf): Replace "Q<U>" constraints for FP addresses with "m" constraints. gcc/testsuite/ 200x-xx-xx Nathan Sidwell <nathan@codesourcery.com> * gcc.dg/m68k-fp-1.c: New. Index: gcc/config/m68k/m68k.h =================================================================== --- gcc/config/m68k/m68k.h 2007-01-09 15:02:05.000000000 +0000 +++ gcc/config/m68k/m68k.h 2007-01-09 15:02:07.000000000 +0000 @@ -470,7 +470,8 @@ #define REG_CLASS_CONTENTS \ extern enum reg_class regno_reg_class[]; #define REGNO_REG_CLASS(REGNO) (regno_reg_class[(REGNO)]) -#define INDEX_REG_CLASS GENERAL_REGS +#define MODE_INDEX_REG_CLASS(MODE) \ + (MODE_OK_FOR_INDEX_P (MODE) ? GENERAL_REGS : NO_REGS) #define BASE_REG_CLASS ADDR_REGS /* We do a trick here to modify the effective constraints on the @@ -737,6 +738,10 @@ #define INITIAL_ELIMINATION_OFFSET(FROM, #define HAVE_POST_INCREMENT 1 #define HAVE_PRE_DECREMENT 1 +/* Return true if addresses of mode MODE can have an index register. */ +#define MODE_OK_FOR_INDEX_P(MODE) \ + (!TARGET_COLDFIRE_FPU || GET_MODE_CLASS (MODE) != MODE_FLOAT) + /* Macros to check register numbers against specific register classes. */ /* True for data registers, D0 through D7. */ @@ -751,9 +756,10 @@ #define INT_REGNO_P(REGNO) ((unsigned in /* True for floating point registers, FP0 through FP7. */ #define FP_REGNO_P(REGNO) (((unsigned int) (REGNO) - 16) < 8) -#define REGNO_OK_FOR_INDEX_P(REGNO) \ - (INT_REGNO_P (REGNO) \ - || INT_REGNO_P (reg_renumber[REGNO])) +#define REGNO_MODE_OK_FOR_INDEX_P(REGNO, MODE) \ + (MODE_OK_FOR_INDEX_P (MODE) \ + && (INT_REGNO_P (REGNO) \ + || INT_REGNO_P (reg_renumber[REGNO]))) #define REGNO_OK_FOR_BASE_P(REGNO) \ (ADDRESS_REGNO_P (REGNO) \ @@ -818,7 +824,8 @@ #define LEGITIMATE_PIC_OPERAND_P(X) \ /* Nonzero if X is a hard reg that can be used as an index or if it is a pseudo reg. */ -#define REG_OK_FOR_INDEX_P(X) !FP_REGNO_P (REGNO (X)) +#define REG_MODE_OK_FOR_INDEX_P(X, MODE) \ + (MODE_OK_FOR_INDEX_P (MODE) && !FP_REGNO_P (REGNO (X))) /* Nonzero if X is a hard reg that can be used as a base reg or if it is a pseudo reg. */ #define REG_OK_FOR_BASE_P(X) \ @@ -827,7 +834,8 @@ #define REG_OK_FOR_BASE_P(X) \ #else /* Nonzero if X is a hard reg that can be used as an index. */ -#define REG_OK_FOR_INDEX_P(X) REGNO_OK_FOR_INDEX_P (REGNO (X)) +#define REG_MODE_OK_FOR_INDEX_P(X, MODE) \ + REGNO_MODE_OK_FOR_INDEX_P (REGNO (X), MODE) /* Nonzero if X is a hard reg that can be used as a base reg. */ #define REG_OK_FOR_BASE_P(X) REGNO_OK_FOR_BASE_P (REGNO (X)) @@ -886,38 +894,38 @@ #define GO_IF_INDEXABLE_BASE(X, ADDR) goto ADDR; \ if (LEGITIMATE_BASE_REG_P (X)) goto ADDR; } -#define GO_IF_INDEXING(X, ADDR) \ -{ if (GET_CODE (X) == PLUS && LEGITIMATE_INDEX_P (XEXP (X, 0))) \ +#define GO_IF_INDEXING(MODE, X, ADDR) \ +{ if (GET_CODE (X) == PLUS && LEGITIMATE_INDEX_P (XEXP (X, 0), MODE)) \ { GO_IF_INDEXABLE_BASE (XEXP (X, 1), ADDR); } \ - if (GET_CODE (X) == PLUS && LEGITIMATE_INDEX_P (XEXP (X, 1))) \ + if (GET_CODE (X) == PLUS && LEGITIMATE_INDEX_P (XEXP (X, 1), MODE)) \ { GO_IF_INDEXABLE_BASE (XEXP (X, 0), ADDR); } } -#define GO_IF_INDEXED_ADDRESS(X, ADDR) \ -{ GO_IF_INDEXING (X, ADDR); \ +#define GO_IF_INDEXED_ADDRESS(MODE, X, ADDR) \ +{ GO_IF_INDEXING (MODE, X, ADDR); \ if (GET_CODE (X) == PLUS) \ { if (GET_CODE (XEXP (X, 1)) == CONST_INT \ && (TARGET_68020 || (unsigned) INTVAL (XEXP (X, 1)) + 0x80 < 0x100)) \ - { rtx go_temp = XEXP (X, 0); GO_IF_INDEXING (go_temp, ADDR); } \ + { rtx go_temp = XEXP (X, 0); GO_IF_INDEXING (MODE, go_temp, ADDR); } \ if (GET_CODE (XEXP (X, 0)) == CONST_INT \ && (TARGET_68020 || (unsigned) INTVAL (XEXP (X, 0)) + 0x80 < 0x100)) \ - { rtx go_temp = XEXP (X, 1); GO_IF_INDEXING (go_temp, ADDR); } } } + { rtx go_temp = XEXP (X, 1); GO_IF_INDEXING (MODE, go_temp, ADDR); } } } /* ColdFire/5200 does not allow HImode index registers. */ -#define LEGITIMATE_INDEX_REG_P(X) \ - ((GET_CODE (X) == REG && REG_OK_FOR_INDEX_P (X)) \ +#define LEGITIMATE_INDEX_REG_P(X, MODE) \ + ((GET_CODE (X) == REG && REG_MODE_OK_FOR_INDEX_P (X, MODE)) \ || (! TARGET_COLDFIRE \ && GET_CODE (X) == SIGN_EXTEND \ && GET_CODE (XEXP (X, 0)) == REG \ && GET_MODE (XEXP (X, 0)) == HImode \ - && REG_OK_FOR_INDEX_P (XEXP (X, 0))) \ + && REG_MODE_OK_FOR_INDEX_P (XEXP (X, 0), MODE)) \ || (GET_CODE (X) == SUBREG \ && GET_CODE (SUBREG_REG (X)) == REG \ - && REG_OK_FOR_INDEX_P (SUBREG_REG (X)))) + && REG_MODE_OK_FOR_INDEX_P (SUBREG_REG (X), MODE))) -#define LEGITIMATE_INDEX_P(X) \ - (LEGITIMATE_INDEX_REG_P (X) \ +#define LEGITIMATE_INDEX_P(X, MODE) \ + (LEGITIMATE_INDEX_REG_P (X, MODE) \ || ((TARGET_68020 || TARGET_COLDFIRE) && GET_CODE (X) == MULT \ - && LEGITIMATE_INDEX_REG_P (XEXP (X, 0)) \ + && LEGITIMATE_INDEX_REG_P (XEXP (X, 0), MODE) \ && GET_CODE (XEXP (X, 1)) == CONST_INT \ && (INTVAL (XEXP (X, 1)) == 2 \ || INTVAL (XEXP (X, 1)) == 4 \ @@ -943,9 +951,9 @@ #define GO_IF_LEGITIMATE_ADDRESS(MODE, X else \ { \ GO_IF_NONINDEXED_ADDRESS (X, ADDR); \ - GO_IF_INDEXED_ADDRESS (X, ADDR); \ + GO_IF_INDEXED_ADDRESS (MODE, X, ADDR); \ if (flag_pic && MODE == CASE_VECTOR_MODE && GET_CODE (X) == PLUS \ - && LEGITIMATE_INDEX_P (XEXP (X, 0)) \ + && LEGITIMATE_INDEX_P (XEXP (X, 0), MODE) \ && GET_CODE (XEXP (X, 1)) == LABEL_REF) \ goto ADDR; \ }} Index: gcc/config/m68k/m68k.md =================================================================== --- gcc/config/m68k/m68k.md 2007-01-09 15:02:04.000000000 +0000 +++ gcc/config/m68k/m68k.md 2007-01-09 15:02:07.000000000 +0000 @@ -271,7 +271,7 @@ (define_insn "tst<mode>_68881" (define_insn "tst<mode>_cf" [(set (cc0) - (match_operand:FP 0 "general_operand" "f<FP:dreg><Q>U"))] + (match_operand:FP 0 "general_operand" "f<FP:dreg>m"))] "TARGET_COLDFIRE_FPU" { cc_status.flags = CC_IN_68881; @@ -434,8 +434,8 @@ (define_insn "cmp<mode>_68881" (define_insn "cmp<mode>_cf" [(set (cc0) - (compare (match_operand:FP 0 "general_operand" "f,<FP:dreg><Q>U") - (match_operand:FP 1 "general_operand" "f<FP:dreg><Q>U,f")))] + (compare (match_operand:FP 0 "general_operand" "f,<FP:dreg>m") + (match_operand:FP 1 "general_operand" "f<FP:dreg>m,f")))] "TARGET_COLDFIRE_FPU" { cc_status.flags = CC_IN_68881; @@ -868,10 +868,8 @@ (define_insn "movsf_cf_soft" }) (define_insn "movsf_cf_hard" - [(set (match_operand:SF 0 "nonimmediate_operand" "=r<Q>U, f, f,mr,f,r<Q>,f -,m") - (match_operand:SF 1 "general_operand" " f, r<Q>U,f,rm,F,F, m -,f"))] + [(set (match_operand:SF 0 "nonimmediate_operand" "=rm,f, f,rm,f,r<Q>,f,m") + (match_operand:SF 1 "general_operand" " f, rm,f,rm,F,F, m,f"))] "TARGET_COLDFIRE_FPU" { if (which_alternative == 4 || which_alternative == 5) { @@ -1011,8 +1009,8 @@ (define_insn "movdf_cf_soft" }) (define_insn "movdf_cf_hard" - [(set (match_operand:DF 0 "nonimmediate_operand" "=f, <Q>U,r,f,r,r,m,f") - (match_operand:DF 1 "general_operand" " f<Q>U,f, f,r,r,m,r,E"))] + [(set (match_operand:DF 0 "nonimmediate_operand" "=f, m,r,f,r,r,m,f") + (match_operand:DF 1 "general_operand" " fm,f,f,r,r,m,r,E"))] "TARGET_COLDFIRE_FPU" { rtx xoperands[3]; @@ -1630,7 +1628,7 @@ (define_insn "" (define_insn "extendsfdf2_cf" [(set (match_operand:DF 0 "nonimmediate_operand" "=f,f") (float_extend:DF - (match_operand:SF 1 "general_operand" "f,<Q>U")))] + (match_operand:SF 1 "general_operand" "f,m")))] "TARGET_COLDFIRE_FPU" { if (FP_REG_P (operands[0]) && FP_REG_P (operands[1])) @@ -1670,9 +1668,9 @@ (define_insn "" }) (define_insn "truncdfsf2_cf" - [(set (match_operand:SF 0 "nonimmediate_operand" "=f,d<Q>U") + [(set (match_operand:SF 0 "nonimmediate_operand" "=f,dm") (float_truncate:SF - (match_operand:DF 1 "general_operand" "<Q>U,f")))] + (match_operand:DF 1 "general_operand" "m,f")))] "TARGET_COLDFIRE_FPU" "@ f%$move%.d %1,%0 @@ -1809,7 +1807,7 @@ (define_insn "ftrunc<mode>2_68881" (define_insn "ftrunc<mode>2_cf" [(set (match_operand:FP 0 "nonimmediate_operand" "=f") - (fix:FP (match_operand:FP 1 "general_operand" "f<FP:dreg><Q>U")))] + (fix:FP (match_operand:FP 1 "general_operand" "f<FP:dreg>m")))] "TARGET_COLDFIRE_FPU" { if (FP_REG_P (operands[1])) @@ -2366,7 +2364,7 @@ (define_insn "add<mode>3_68881" (define_insn "add<mode>3_cf" [(set (match_operand:FP 0 "nonimmediate_operand" "=f") (plus:FP (match_operand:FP 1 "general_operand" "%0") - (match_operand:FP 2 "general_operand" "f<FP:dreg><Q>U")))] + (match_operand:FP 2 "general_operand" "f<FP:dreg>m")))] "TARGET_COLDFIRE_FPU" { if (FP_REG_P (operands[2])) @@ -2575,7 +2573,7 @@ (define_insn "sub<mode>3_68881" (define_insn "sub<mode>3_cf" [(set (match_operand:FP 0 "nonimmediate_operand" "=f") (minus:FP (match_operand:FP 1 "general_operand" "0") - (match_operand:FP 2 "general_operand" "f<FP:dreg><Q>U")))] + (match_operand:FP 2 "general_operand" "f<FP:dreg>m")))] "TARGET_COLDFIRE_FPU" { if (FP_REG_P (operands[2])) @@ -2909,7 +2907,7 @@ (define_insn "mulxf3_68881" (define_insn "fmul<mode>3_cf" [(set (match_operand:FP 0 "nonimmediate_operand" "=f") (mult:FP (match_operand:FP 1 "general_operand" "%0") - (match_operand:FP 2 "general_operand" "f<Q>U<FP:dreg>")))] + (match_operand:FP 2 "general_operand" "fm<FP:dreg>")))] "TARGET_COLDFIRE_FPU" { if (FP_REG_P (operands[2])) @@ -2977,7 +2975,7 @@ (define_insn "div<mode>3_68881" (define_insn "div<mode>3_cf" [(set (match_operand:FP 0 "nonimmediate_operand" "=f") (div:FP (match_operand:FP 1 "general_operand" "0") - (match_operand:FP 2 "general_operand" "f<Q>U<FP:dreg>")))] + (match_operand:FP 2 "general_operand" "fm<FP:dreg>")))] "TARGET_COLDFIRE_FPU" { if (FP_REG_P (operands[2])) @@ -3817,7 +3815,7 @@ (define_insn "neg<mode>2_68881" (define_insn "neg<mode>2_cf" [(set (match_operand:FP 0 "nonimmediate_operand" "=f,d") - (neg:FP (match_operand:FP 1 "general_operand" "f<FP:dreg><Q>U,0")))] + (neg:FP (match_operand:FP 1 "general_operand" "f<FP:dreg>m,0")))] "TARGET_COLDFIRE_FPU" { if (DATA_REG_P (operands[0])) @@ -3850,7 +3848,7 @@ (define_insn "sqrt<mode>2_68881" (define_insn "sqrt<mode>2_cf" [(set (match_operand:FP 0 "nonimmediate_operand" "=f") - (sqrt:FP (match_operand:FP 1 "general_operand" "f<FP:dreg><Q>U")))] + (sqrt:FP (match_operand:FP 1 "general_operand" "f<FP:dreg>m")))] "TARGET_COLDFIRE_FPU" { if (FP_REG_P (operands[1])) @@ -3968,7 +3966,7 @@ (define_insn "abs<mode>2_68881" (define_insn "abs<mode>2_cf" [(set (match_operand:FP 0 "nonimmediate_operand" "=f,d") - (abs:FP (match_operand:FP 1 "general_operand" "f<FP:dreg><Q>U,0")))] + (abs:FP (match_operand:FP 1 "general_operand" "f<FP:dreg>m,0")))] "TARGET_COLDFIRE_FPU" { if (DATA_REG_P (operands[0])) Index: gcc/testsuite/gcc.dg/m68k-fp-1.c =================================================================== --- /dev/null 2007-01-09 03:39:34.548096750 +0000 +++ gcc/testsuite/gcc.dg/m68k-fp-1.c 2007-01-09 15:02:07.000000000 +0000 @@ -0,0 +1,13 @@ +/* ColdFire has restricted addressing modes for float operands. */ +/* { dg-do compile { target m68k-*-* } } */ +/* { dg-options "-O0 -mcpu=547x -mhard-float" } */ + +double Foo (unsigned a) +{ + unsigned local_data[16384] __attribute__((unused)); + double d; + + d = a; + + return d; +} ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 26/63] Rework the call and jump handling 2007-01-10 11:24 ` [ColdFire 25/63] Define MODE_INDEX_REG_CLASS for m68k Richard Sandiford @ 2007-01-10 11:28 ` Richard Sandiford 2007-01-10 11:32 ` [ColdFire 27/63] Addressing mode changes and fixes Richard Sandiford 2007-01-11 17:30 ` [ColdFire 26/63] Rework the call and jump handling Jeffrey Law 0 siblings, 2 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 11:28 UTC (permalink / raw) To: gcc-patches This patch reworks the call and jump code. There are four main aims: - To expose the GOT load in m68k_output_pic_call. This has two benefits: it allows the load to be CSEd, and it removes the need for this code in m68k_save_reg: if (flag_pic && regno == PIC_OFFSET_TABLE_REGNUM) { ... if (!current_function_is_leaf && TARGET_ID_SHARED_LIBRARY) return true; } (which a later patch will remove). - To allow bra.l and bsr.l to be used for PIC calls on ISA B ColdFire targets. - To fix the sequences generated when long branches are not available. The current code reads: else if (optimize_size || TARGET_ID_SHARED_LIBRARY) out = "move.l %0@GOT(%%a5), %%a1\n\tjsr (%%a1)"; else out = "lea %0-.-8,%%a1\n\tjsr 0(%%pc,%%a1)"; but the final case isn't always safe. One of %a0 and %a1 is the incoming return address pointer and the other is the static chain register (which register is which depends on the configuration). (Actually, this isn't true for *-elf on mainline, but it ought to be. A later patch deals with this.) - To fix the potential problems with the SYMBOL_REF_FLAG handling. At the moment, the port sets SYMBOL_REF_FLAG if a symbol is used as a call target, and it will then be accepted as a legitimate PIC constant. However, the symbol could in principle be used in non-call situations too, and we don't want it to be accepted as an absolute address. This is admittedly more of a theoretical concern. The code for calls is very similar to the code for jumps -- it's basically just a bsr/jsr vs. bra/jmp choice -- so it would be nice to have only one copy of the logic. The patch therefore stores the call sequences for symbolic addresses in two new global strings -- m68k_symbolic_call and m68k_symbolic_jump -- and sets them both up in OVERRIDE_OPTIONS. These variables are null if no symbolic calls are allowed; the address will then be loaded from the GOT. The patch avoids the use of SYMBOL_REF_FLAG by defining a new 'W' constraint for constant call addresses. The patch also removes the only use of the %o operand prefix, which TARGET_PCREL used to output illegitimate MEMs. It therefore removes the associated print_operand code too. (I don't think any user asms would use %o because asms will never see illegitimate MEMs.) Richard gcc/ * config/m68k/m68k-protos.h (m68k_output_pic_call): Delete. (output_call, m68k_legitimize_call_address): Declare. * config/m68k/m68k.h (EXTRA_CONSTRAINT): Remove unnecessary parenthesees. Add support for a 'W' constraint. (LEGITIMATE_PIC_OPERAND_P): Remove SYMBOL_REF_FLAG handling. (PRINT_OPERAND_PUNCT_VALID_P): Remove comment about 'o'. (m68k_symbolic_call, m68k_symbolic_jump): Declare. * config/m68k/m68k.c (m68k_symbolic_call, m68k_symbolic_jump): New variables. (override_options): Initialize them. Do not set flag_no_function_cse for TARGET_ID_SHARED_LIBRARY. (m68k_output_pic_call): Delete. (m68k_legitimize_call_address): New function. (print_operand): Remove the %o prefix. Handle the %p prefix. (output_call): New function. (m68k_output_mi_thunk): Use m68k_symbolic_jump. Always load the target address from the GOT if symbolic jumps are not allowed. * config/m68k/m68k.md (call, general_operand): Do not set SYMBOL_REF_FLAG. Use m68k_legitimize_call_address instead. Merge separate flag_pic and !flag_pic define_insns into... (*call, *call_value): ...these new patterns. Match the address rather than the containing MEM and require it to be a call_operand. Use output_call to generate the asm template. * config/m68k/predicates.md (const_call_operand): New predicate. (call_operand): Likewise. Index: gcc/config/m68k/m68k-protos.h =================================================================== --- gcc/config/m68k/m68k-protos.h 2007-01-09 15:01:56.000000000 +0000 +++ gcc/config/m68k/m68k-protos.h 2007-01-09 15:02:08.000000000 +0000 @@ -39,7 +39,7 @@ extern const char *output_addsi3 (rtx *) extern const char *output_andsi3 (rtx *); extern const char *output_iorsi3 (rtx *); extern const char *output_xorsi3 (rtx *); -extern void m68k_output_pic_call (rtx dest); +extern const char *output_call (rtx); extern void output_dbcc_and_branch (rtx *); extern int floating_exact_log2 (rtx); extern bool strict_low_part_peephole_ok (enum machine_mode mode, rtx first_insn, rtx target); @@ -65,4 +65,5 @@ extern void override_options (void); extern const char *m68k_cpp_cpu_ident (const char *); extern const char *m68k_cpp_cpu_family (const char *); extern void init_68881_table (void); +extern rtx m68k_legitimize_call_address (rtx); extern int m68k_hard_regno_rename_ok(unsigned int, unsigned int); Index: gcc/config/m68k/m68k.h =================================================================== --- gcc/config/m68k/m68k.h 2007-01-09 15:02:07.000000000 +0000 +++ gcc/config/m68k/m68k.h 2007-01-09 15:02:08.000000000 +0000 @@ -514,32 +514,35 @@ #define CONST_DOUBLE_OK_FOR_LETTER_P(VAL /* `Q' means address register indirect addressing mode. `S' is for operands that satisfy 'm' when -mpcrel is in effect. `T' is for operands that satisfy 's' when -mpcrel is not in effect. - `U' is for register offset addressing. */ + `U' is for register offset addressing. + `W' is for const_call_operands. */ #define EXTRA_CONSTRAINT(OP,CODE) \ - (((CODE) == 'S') \ + ((CODE) == 'S' \ ? (TARGET_PCREL \ && GET_CODE (OP) == MEM \ && (GET_CODE (XEXP (OP, 0)) == SYMBOL_REF \ || GET_CODE (XEXP (OP, 0)) == LABEL_REF \ || GET_CODE (XEXP (OP, 0)) == CONST)) \ : \ - (((CODE) == 'T') \ + (CODE) == 'T' \ ? ( !TARGET_PCREL \ && (GET_CODE (OP) == SYMBOL_REF \ || GET_CODE (OP) == LABEL_REF \ || GET_CODE (OP) == CONST)) \ : \ - (((CODE) == 'Q') \ + (CODE) == 'Q' \ ? (GET_CODE (OP) == MEM \ && GET_CODE (XEXP (OP, 0)) == REG) \ : \ - (((CODE) == 'U') \ + (CODE) == 'U' \ ? (GET_CODE (OP) == MEM \ && GET_CODE (XEXP (OP, 0)) == PLUS \ && GET_CODE (XEXP (XEXP (OP, 0), 0)) == REG \ && GET_CODE (XEXP (XEXP (OP, 0), 1)) == CONST_INT) \ : \ - 0)))) + (CODE) == 'W' \ + ? const_call_operand (OP, VOIDmode) \ + : 0) /* On the m68k, use a data reg if possible when the value is a constant in the range where moveq could be used @@ -817,7 +820,6 @@ #define PCREL_GENERAL_OPERAND_OK (TARGET #define LEGITIMATE_PIC_OPERAND_P(X) \ (! symbolic_operand (X, VOIDmode) \ - || (GET_CODE (X) == SYMBOL_REF && SYMBOL_REF_FLAG (X)) \ || PCREL_GENERAL_OPERAND_OK) #ifndef REG_OK_STRICT @@ -1248,8 +1250,6 @@ #define ASM_OUTPUT_LONG_DOUBLE_OPERAND(F 'b' for byte insn (no effect, on the Sun; this is for the ISI). 'd' to force memory addressing to be absolute, not relative. 'f' for float insn (print a CONST_DOUBLE as a float rather than in hex) - 'o' for operands to go directly to output_operand_address (bypassing - print_operand_address--used only for SYMBOL_REFs under TARGET_PCREL) 'x' for float insn (print a CONST_DOUBLE as a float rather than in hex), or print pair of registers as rx:ry. */ @@ -1308,3 +1308,5 @@ enum fpu_type extern enum uarch_type m68k_tune; extern enum fpu_type m68k_fpu; extern unsigned int m68k_cpu_flags; +extern const char *m68k_symbolic_call; +extern const char *m68k_symbolic_jump; Index: gcc/config/m68k/m68k.c =================================================================== --- gcc/config/m68k/m68k.c 2007-01-09 15:02:05.000000000 +0000 +++ gcc/config/m68k/m68k.c 2007-01-09 15:02:08.000000000 +0000 @@ -330,6 +330,12 @@ enum fpu_type m68k_fpu; /* The set of FL_* flags that apply to the target processor. */ unsigned int m68k_cpu_flags; + +/* Asm templates for calling or jumping to an arbitrary symbolic address, + or NULL if such calls or jumps are not supported. The address is held + in operand 0. */ +const char *m68k_symbolic_call; +const char *m68k_symbolic_jump; \f /* See whether TABLE has an entry with name NAME. Return true and store the entry in *ENTRY if so, otherwise return false and @@ -533,13 +539,42 @@ override_options (void) if (TARGET_PCREL && flag_pic == 0) flag_pic = 1; - /* Turn off function cse if we are doing PIC. We always want function call - to be done as `bsr foo@PLTPC', so it will force the assembler to create - the PLT entry for `foo'. Doing function cse will cause the address of - `foo' to be loaded into a register, which is exactly what we want to - avoid when we are doing PIC on svr4 m68k. */ - if (flag_pic) - flag_no_function_cse = 1; + if (!flag_pic) + { +#if MOTOROLA && !defined (USE_GAS) + m68k_symbolic_call = "jsr %a0"; + m68k_symbolic_jump = "jmp %a0"; +#else + m68k_symbolic_call = "jbsr %a0"; + m68k_symbolic_jump = "jra %a0"; +#endif + } + else if (TARGET_ID_SHARED_LIBRARY) + /* All addresses must be loaded from the GOT. */ + ; + else if (TARGET_68020 || TARGET_ISAB) + { + if (TARGET_PCREL) + { + m68k_symbolic_call = "bsr.l %c0"; + m68k_symbolic_jump = "bra.l %c0"; + } + else + { +#if defined(USE_GAS) + m68k_symbolic_call = "bsr.l %p0"; + m68k_symbolic_jump = "bra.l %p0"; +#else + m68k_symbolic_call = "bsr %p0"; + m68k_symbolic_jump = "bra %p0"; +#endif + } + /* Turn off function cse if we are doing PIC. We always want + function call to be done as `bsr foo@PLTPC'. */ + /* ??? It's traditional to do this for -mpcrel too, but it isn't + clear how intentional that is. */ + flag_no_function_cse = 1; + } SUBTARGET_OVERRIDE_OPTIONS; } @@ -1335,33 +1370,16 @@ flags_in_68881 (void) return cc_status.flags & CC_IN_68881; } -/* Output a BSR instruction suitable for PIC code. */ -void -m68k_output_pic_call (rtx dest) -{ - const char *out; - - if (!(GET_CODE (dest) == MEM && GET_CODE (XEXP (dest, 0)) == SYMBOL_REF)) - out = "jsr %0"; - /* We output a BSR instruction if we're building for a target that - supports long branches. Otherwise we generate one of two sequences: - a shorter one that uses a GOT entry or a longer one that doesn't. - We'll use the -Os command-line flag to decide which to generate. - Both sequences take the same time to execute on the ColdFire. */ - else if (TARGET_PCREL) - out = "bsr.l %o0"; - else if (TARGET_68020) -#if defined(USE_GAS) - out = "bsr.l %0@PLTPC"; -#else - out = "bsr %0@PLTPC"; -#endif - else if (optimize_size || TARGET_ID_SHARED_LIBRARY) - out = "move.l %0@GOT(%%a5), %%a1\n\tjsr (%%a1)"; - else - out = "lea %0-.-8,%%a1\n\tjsr 0(%%pc,%%a1)"; +/* Convert X to a legitimate function call memory reference and return the + result. */ - output_asm_insn (out, &dest); +rtx +m68k_legitimize_call_address (rtx x) +{ + gcc_assert (MEM_P (x)); + if (call_operand (XEXP (x, 0), VOIDmode)) + return x; + return replace_equiv_address (x, force_reg (Pmode, XEXP (x, 0))); } /* Output a dbCC; jCC sequence. Note we do not handle the @@ -3103,12 +3121,10 @@ floating_exact_log2 (rtx x) 'b' for byte insn (no effect, on the Sun; this is for the ISI). 'd' to force memory addressing to be absolute, not relative. 'f' for float insn (print a CONST_DOUBLE as a float rather than in hex) - 'o' for operands to go directly to output_operand_address (bypassing - print_operand_address--used only for SYMBOL_REFs under TARGET_PCREL) 'x' for float insn (print a CONST_DOUBLE as a float rather than in hex), or print pair of registers as rx:ry. - - */ + 'p' print an address with @PLTPC attached, but only if the operand + is not locally-bound. */ void print_operand (FILE *file, rtx op, int letter) @@ -3140,13 +3156,11 @@ print_operand (FILE *file, rtx op, int l } else if (letter == '/') asm_fprintf (file, "%R"); - else if (letter == 'o') + else if (letter == 'p') { - /* This is only for direct addresses with TARGET_PCREL */ - gcc_assert (GET_CODE (op) == MEM - && GET_CODE (XEXP (op, 0)) == SYMBOL_REF - && TARGET_PCREL); - output_addr_const (file, XEXP (op, 0)); + output_addr_const (file, op); + if (!(GET_CODE (op) == SYMBOL_REF && SYMBOL_REF_LOCAL_P (op))) + fprintf (file, "@PLTPC"); } else if (GET_CODE (op) == REG) { @@ -3713,6 +3727,18 @@ output_xorsi3 (rtx *operands) return "eor%.l %2,%0"; } +/* Return the instruction that should be used for a call to address X, + which is known to be in operand 0. */ + +const char * +output_call (rtx x) +{ + if (symbolic_operand (x, VOIDmode)) + return m68k_symbolic_call; + else + return "jsr %a0"; +} + #ifdef M68K_TARGET_COFF /* Output assembly to switch to section NAME with attribute FLAGS. */ @@ -3779,43 +3805,13 @@ m68k_output_mi_thunk (FILE *file, tree t xops[0] = DECL_RTL (function); - /* Logic taken from call patterns in m68k.md. */ - if (flag_pic) - { - if (TARGET_PCREL) - fmt = "bra.l %o0"; - else if (flag_pic == 1 || TARGET_68020) - { - if (MOTOROLA) - { -#if defined (USE_GAS) - fmt = "bra.l %0@PLTPC"; -#else - fmt = "bra %0@PLTPC"; -#endif - } - else /* !MOTOROLA */ - { -#ifdef USE_GAS - fmt = "bra.l %0"; -#else - fmt = "jra %0,a1"; -#endif - } - } - else if (optimize_size || TARGET_ID_SHARED_LIBRARY) - fmt = "move.l %0@GOT(%%a5), %%a1\n\tjmp (%%a1)"; - else - fmt = "lea %0-.-8,%%a1\n\tjmp 0(%%pc,%%a1)"; - } - else - { -#if MOTOROLA && !defined (USE_GAS) - fmt = "jmp %0"; -#else - fmt = "jra %0"; -#endif - } + gcc_assert (MEM_P (xops[0]) + && symbolic_operand (XEXP (xops[0], 0), VOIDmode)); + xops[0] = XEXP (xops[0], 0); + + fmt = m68k_symbolic_jump; + if (m68k_symbolic_jump == NULL) + fmt = "move.l %%a1@GOT(%%a5), %%a1\n\tjmp (%%a1)"; output_asm_insn (fmt, xops); } Index: gcc/config/m68k/m68k.md =================================================================== --- gcc/config/m68k/m68k.md 2007-01-09 15:02:07.000000000 +0000 +++ gcc/config/m68k/m68k.md 2007-01-09 15:02:08.000000000 +0000 @@ -6383,122 +6383,46 @@ (define_insn "" "subql #1,%0\;cmpl #-1,%0\;jne %l1"; }) - -;; For PIC calls, in order to be able to support -;; dynamic linker LAZY BINDING, all the procedure calls need to go -;; through the PLT (Procedure Linkage Table) section in PIC mode. -;; -;; PIC calls are handled by loading the address of the function into a -;; register (via movsi), then emitting a register indirect call using -;; the "jsr" function call syntax. -;; -;; When outputting MIT syntax (e.g. on Suns), we add a bogus extra -;; operand to the jbsr statement to indicate that this call should -;; go through the PLT (why? because this is the way that Sun does it). -;; -;; We have different patterns for PIC calls and non-PIC calls. The -;; different patterns are only used to choose the right syntax. -;; -;; The svr4 m68k assembler recognizes this syntax: `bsr FUNC@PLTPC' and it -;; will create the correct relocation entry (R_68K_PLT32) for `FUNC', -;; that tells the linker editor to create an entry for `FUNC' in PLT -;; section at link time. However, all global objects reference are still -;; done by using `OBJ@GOT'. So, the goal here is to output the function -;; call operand as `FUNC@PLTPC', but output object operand as `OBJ@GOT'. -;; We need to have a way to differentiate these two different operands. -;; -;; The strategy I use here is to use SYMBOL_REF_FLAG to differentiate -;; these two different operands. The macro LEGITIMATE_PIC_OPERAND_P needs -;; to be changed to recognize function calls symbol_ref operand as a valid -;; PIC operand (by checking whether SYMBOL_REF_FLAG is set). This will -;; avoid the compiler to load this symbol_ref operand into a register. -;; Remember, the operand "foo@PLTPC" cannot be called via jsr directly -;; since the value is a PC relative offset, not a real address. -;; -;; All global objects are treated in the similar way as in SUN3. The only -;; difference is: on m68k svr4, the reference of such global object needs -;; to end with a suffix "@GOT" so the assembler and linker know to create -;; an entry for it in GOT (Global Offset Table) section. This is done in -;; m68k.c. - ;; Call subroutine with no return value. (define_expand "call" [(call (match_operand:QI 0 "memory_operand" "") (match_operand:SI 1 "general_operand" ""))] ;; Operand 1 not really used on the m68000. - "" { - if (flag_pic && GET_CODE (XEXP (operands[0], 0)) == SYMBOL_REF) - SYMBOL_REF_FLAG (XEXP (operands[0], 0)) = 1; + operands[0] = m68k_legitimize_call_address (operands[0]); }) -;; This is a normal call sequence. -(define_insn "" - [(call (match_operand:QI 0 "memory_operand" "o") - (match_operand:SI 1 "general_operand" "g"))] +(define_insn "*call" + [(call (mem:QI (match_operand:SI 0 "call_operand" "a,W")) + (match_operand:SI 1 "general_operand" "g,g"))] ;; Operand 1 not really used on the m68000. - - "! flag_pic" -{ -#if MOTOROLA && !defined (USE_GAS) - return "jsr %0"; -#else - return "jbsr %0"; -#endif -}) - -;; This is a PIC call sequence. -(define_insn "" - [(call (match_operand:QI 0 "memory_operand" "o") - (match_operand:SI 1 "general_operand" "g"))] - ;; Operand 1 not really used on the m68000. - - "flag_pic" + "" { - m68k_output_pic_call(operands[0]); - return ""; + return output_call (operands[0]); }) ;; Call subroutine, returning value in operand 0 ;; (which must be a hard register). -;; See comments before "call" regarding PIC calls. (define_expand "call_value" [(set (match_operand 0 "" "") (call (match_operand:QI 1 "memory_operand" "") - (match_operand:SI 2 "general_operand" "")))] + (match_operand:SI 2 "general_operand" "")))] ;; Operand 2 not really used on the m68000. "" { - if (flag_pic && GET_CODE (XEXP (operands[1], 0)) == SYMBOL_REF) - SYMBOL_REF_FLAG (XEXP (operands[1], 0)) = 1; + operands[1] = m68k_legitimize_call_address (operands[1]); }) -;; This is a normal call_value -(define_insn "" - [(set (match_operand 0 "" "=rf") - (call (match_operand:QI 1 "memory_operand" "o") - (match_operand:SI 2 "general_operand" "g")))] +(define_insn "*call_value" + [(set (match_operand 0 "" "=rf,rf") + (call (mem:QI (match_operand:SI 1 "call_operand" "a,W")) + (match_operand:SI 2 "general_operand" "g,g")))] ;; Operand 2 not really used on the m68000. - "! flag_pic" -{ -#if MOTOROLA && !defined (USE_GAS) - return "jsr %1"; -#else - return "jbsr %1"; -#endif -}) - -;; This is a PIC call_value -(define_insn "" - [(set (match_operand 0 "" "=rf") - (call (match_operand:QI 1 "memory_operand" "o") - (match_operand:SI 2 "general_operand" "g")))] - ;; Operand 2 not really used on the m68000. - "flag_pic" + "" { - m68k_output_pic_call(operands[1]); - return ""; + operands[0] = operands[1]; + return output_call (operands[0]); }) ;; Call subroutine returning any type. Index: gcc/config/m68k/predicates.md =================================================================== --- gcc/config/m68k/predicates.md 2007-01-09 15:01:41.000000000 +0000 +++ gcc/config/m68k/predicates.md 2007-01-09 15:02:08.000000000 +0000 @@ -159,6 +159,17 @@ (define_predicate "symbolic_operand" } }) +;; A constant that can be used the address in a call insn. +(define_predicate "const_call_operand" + (ior (match_operand 0 "const_int_operand") + (and (match_test "m68k_symbolic_call != NULL") + (match_operand 0 "symbolic_operand")))) + +;; An operand that can be used as the address in a call insn. +(define_predicate "call_operand" + (ior (match_operand 0 "const_call_operand") + (match_operand 0 "register_operand"))) + ;; TODO: Add a comment here. (define_predicate "post_inc_operand" ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 27/63] Addressing mode changes and fixes 2007-01-10 11:28 ` [ColdFire 26/63] Rework the call and jump handling Richard Sandiford @ 2007-01-10 11:32 ` Richard Sandiford 2007-01-10 11:34 ` [middle-end, ColdFire 28/63] Change the canonical NaN representation Richard Sandiford 2007-01-11 17:30 ` [ColdFire 26/63] Rework the call and jump handling Jeffrey Law 1 sibling, 1 reply; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 11:32 UTC (permalink / raw) To: gcc-patches This patch rewrites the m68k address handling. The main change is to add an m68k_decompose_address function, in a similar vein to the i386 port. This function is then used for both GO_IF_LEGITIMATE_ADDRESS and PRINT_OPERAND_ADDRESS. The patch fixes the problem I mentioned in an earlier message: if the address has a constant component, and that component has a limited range, we can ICE if we convert a legitimate MEM into smaller MEMs. For example, 0x7c(%a0,%d0) is currently a legitimate DImode address on ColdFire and plain 68000, but 0x80(0xa0,%d0) is not a legitimate SImode address. DImode patterns might try to create the latter from the former. The approach I've taken is to use the offset for the first byte in the MEM when checking the lower bound and the offset for the last byte when checking the upper bound. Thus a MEM is only legitimate if every possible sub-MEM is also legitimate. This might seem a little draconian, but various output patterns generate HImode and QImode MEMs from SImode ones, not just SImodes from DImodes, so I think a general fix is justified. The patch also extends the range of addresses accepted for 68020 and above. At the moment, we don't allow (bd,An,Xn.SIZE*SCALE) addresses in which "bd" is a symbolic constant. Thus things like: extern int x[]; ...x[y]... do not use (x,y.l*4), even though that's presumably what the mode was designed for. It loads "x" into an address register instead. I'm not sure if this was deliberate or not; if it was, it's easy to go back to the old behaviour. The patch also uses m68k_decompose_address to implement the 'Q' and 'U' constraints. This enforces the rule that memory constraints should only accept legitimate memories; it's a variant of: http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01534.html Richard gcc/ PR target/23482 PR target/17114 * config/m68k/m68k-protos.h (m68k_legitimate_base_reg_p): Declare. (m68k_legitimate_index_reg_p, m68k_legitimate_address_p): Likewise. (m68k_matches_q_p, m68k_matches_u_p): Likewise. * config/m68k/m68k.h (EXTRA_CONSTRAINT): Use m68k_matches_q_p and m68k_matches_u_p. (PCREL_GENERAL_OPERAND_OK, LEGITIMATE_BASE_REG_P): Delete. (INDIRECTABLE_1_ADDRESS_P, GO_IF_NONINDEXED_ADDRESS): Delete. (GO_IF_INDEXABLE_BASE, GO_IF_INDEXING, GO_IF_INDEXED_ADDRESS): Delete. (LEGITIMATE_INDEX_REG_P, LEGITIMATE_INDEX_P): Delete. (GO_IF_COLDFIRE_FPU_LEGITIMATE_ADDRESS): Delete. (REG_STRICT_P): New macro. (LEGITIMATE_PIC_OPERAND_P): Use REG_STRICT_P rather than PCREL_GENERAL_OPERAND_OK. (REG_OK_FOR_BASE_P): Merge definitions. Use REG_STRICT_P and m68k_legitimate_base_reg_p. (REG_MODE_OK_FOR_INDEX_P): Likewise m68k_legitimate_index_reg_p. (GO_IF_LEGITIMATE_ADDRESS): Likewise m68k_legitimate_address_p. (PIC_CASE_VECTOR_ADDRESS): Update comment. * config/m68k/m68k.c (m68k_address): New structure. (m68k_legitimate_base_reg_p, m68k_legitimate_index_reg_p) (m68k_decompose_index, m68k_legitimate_constant_address_p) (m68k_jump_table_ref_p, m68k_decompose_address) (m68k_legitimate_address_p, m68k_legitimate_mem_p, m68k_matches_q_p) (m68k_matches_u_p): New functions. (print_operand_address): Rewrite to use m68k_decompose_index. Index: gcc/config/m68k/m68k-protos.h =================================================================== *** gcc/config/m68k/m68k-protos.h 2007-01-09 15:02:08.000000000 +0000 --- gcc/config/m68k/m68k-protos.h 2007-01-09 15:02:09.000000000 +0000 *************** extern int standard_68881_constant_p (rt *** 49,55 **** --- 49,60 ---- extern void print_operand_address (FILE *, rtx); extern void print_operand (FILE *, rtx, int); extern void notice_update_cc (rtx, rtx); + extern bool m68k_legitimate_base_reg_p (rtx, bool); + extern bool m68k_legitimate_index_reg_p (enum machine_mode, rtx, bool); extern bool m68k_illegitimate_symbolic_constant_p (rtx); + extern bool m68k_legitimate_address_p (enum machine_mode, rtx, bool); + extern bool m68k_matches_q_p (rtx); + extern bool m68k_matches_u_p (rtx); extern rtx legitimize_pic_address (rtx, enum machine_mode, rtx); extern int valid_dbcc_comparison_p_2 (rtx, enum machine_mode); extern rtx m68k_libcall_value (enum machine_mode); Index: gcc/config/m68k/m68k.h =================================================================== *** gcc/config/m68k/m68k.h 2007-01-09 15:02:08.000000000 +0000 --- gcc/config/m68k/m68k.h 2007-01-09 15:02:09.000000000 +0000 *************** #define EXTRA_CONSTRAINT(OP,CODE) \ *** 531,544 **** || GET_CODE (OP) == CONST)) \ : \ (CODE) == 'Q' \ ! ? (GET_CODE (OP) == MEM \ ! && GET_CODE (XEXP (OP, 0)) == REG) \ : \ (CODE) == 'U' \ ! ? (GET_CODE (OP) == MEM \ ! && GET_CODE (XEXP (OP, 0)) == PLUS \ ! && GET_CODE (XEXP (XEXP (OP, 0), 0)) == REG \ ! && GET_CODE (XEXP (XEXP (OP, 0), 1)) == CONST_INT) \ : \ (CODE) == 'W' \ ? const_call_operand (OP, VOIDmode) \ --- 531,540 ---- || GET_CODE (OP) == CONST)) \ : \ (CODE) == 'Q' \ ! ? m68k_matches_q_p (OP) \ : \ (CODE) == 'U' \ ! ? m68k_matches_u_p (OP) \ : \ (CODE) == 'W' \ ? const_call_operand (OP, VOIDmode) \ *************** #define LEGITIMATE_CONSTANT_P(X) \ *** 813,967 **** && !m68k_illegitimate_symbolic_constant_p (X)) #ifndef REG_OK_STRICT ! #define PCREL_GENERAL_OPERAND_OK 0 #else ! #define PCREL_GENERAL_OPERAND_OK (TARGET_PCREL) #endif ! #define LEGITIMATE_PIC_OPERAND_P(X) \ ! (! symbolic_operand (X, VOIDmode) \ ! || PCREL_GENERAL_OPERAND_OK) - #ifndef REG_OK_STRICT - - /* Nonzero if X is a hard reg that can be used as an index - or if it is a pseudo reg. */ - #define REG_MODE_OK_FOR_INDEX_P(X, MODE) \ - (MODE_OK_FOR_INDEX_P (MODE) && !FP_REGNO_P (REGNO (X))) - /* Nonzero if X is a hard reg that can be used as a base reg - or if it is a pseudo reg. */ #define REG_OK_FOR_BASE_P(X) \ ! (!DATA_REGNO_P (REGNO (X)) && !FP_REGNO_P (REGNO (X))) - #else - - /* Nonzero if X is a hard reg that can be used as an index. */ #define REG_MODE_OK_FOR_INDEX_P(X, MODE) \ ! REGNO_MODE_OK_FOR_INDEX_P (REGNO (X), MODE) ! /* Nonzero if X is a hard reg that can be used as a base reg. */ ! #define REG_OK_FOR_BASE_P(X) REGNO_OK_FOR_BASE_P (REGNO (X)) - #endif - \f - /* GO_IF_LEGITIMATE_ADDRESS recognizes an RTL expression - that is a valid memory address for an instruction. - The MODE argument is the machine mode for the MEM expression - that wants to use this address. - - When generating PIC, an address involving a SYMBOL_REF is legitimate - if and only if it is the sum of pic_offset_table_rtx and the SYMBOL_REF. - We use LEGITIMATE_PIC_OPERAND_P to throw out the illegitimate addresses, - and we explicitly check for the sum of pic_offset_table_rtx and a SYMBOL_REF. - - Likewise for a LABEL_REF when generating PIC. - - The other macros defined here are used only in GO_IF_LEGITIMATE_ADDRESS. */ - - /* Allow SUBREG everywhere we allow REG. This results in better code. It - also makes function inlining work when inline functions are called with - arguments that are SUBREGs. */ - - #define LEGITIMATE_BASE_REG_P(X) \ - ((GET_CODE (X) == REG && REG_OK_FOR_BASE_P (X)) \ - || (GET_CODE (X) == SUBREG \ - && GET_CODE (SUBREG_REG (X)) == REG \ - && REG_OK_FOR_BASE_P (SUBREG_REG (X)))) - - #define INDIRECTABLE_1_ADDRESS_P(X) \ - ((CONSTANT_ADDRESS_P (X) && (!flag_pic || LEGITIMATE_PIC_OPERAND_P (X))) \ - || LEGITIMATE_BASE_REG_P (X) \ - || ((GET_CODE (X) == PRE_DEC || GET_CODE (X) == POST_INC) \ - && LEGITIMATE_BASE_REG_P (XEXP (X, 0))) \ - || (GET_CODE (X) == PLUS \ - && LEGITIMATE_BASE_REG_P (XEXP (X, 0)) \ - && GET_CODE (XEXP (X, 1)) == CONST_INT \ - && (TARGET_68020 \ - || ((unsigned) INTVAL (XEXP (X, 1)) + 0x8000) < 0x10000)) \ - || (GET_CODE (X) == PLUS && XEXP (X, 0) == pic_offset_table_rtx \ - && flag_pic && GET_CODE (XEXP (X, 1)) == SYMBOL_REF) \ - || (GET_CODE (X) == PLUS && XEXP (X, 0) == pic_offset_table_rtx \ - && flag_pic && GET_CODE (XEXP (X, 1)) == LABEL_REF)) - - #define GO_IF_NONINDEXED_ADDRESS(X, ADDR) \ - { if (INDIRECTABLE_1_ADDRESS_P (X)) goto ADDR; } - - /* Only labels on dispatch tables are valid for indexing from. */ - #define GO_IF_INDEXABLE_BASE(X, ADDR) \ - { rtx temp; \ - if (GET_CODE (X) == LABEL_REF \ - && (temp = next_nonnote_insn (XEXP (X, 0))) != 0 \ - && GET_CODE (temp) == JUMP_INSN \ - && (GET_CODE (PATTERN (temp)) == ADDR_VEC \ - || GET_CODE (PATTERN (temp)) == ADDR_DIFF_VEC)) \ - goto ADDR; \ - if (LEGITIMATE_BASE_REG_P (X)) goto ADDR; } - - #define GO_IF_INDEXING(MODE, X, ADDR) \ - { if (GET_CODE (X) == PLUS && LEGITIMATE_INDEX_P (XEXP (X, 0), MODE)) \ - { GO_IF_INDEXABLE_BASE (XEXP (X, 1), ADDR); } \ - if (GET_CODE (X) == PLUS && LEGITIMATE_INDEX_P (XEXP (X, 1), MODE)) \ - { GO_IF_INDEXABLE_BASE (XEXP (X, 0), ADDR); } } - - #define GO_IF_INDEXED_ADDRESS(MODE, X, ADDR) \ - { GO_IF_INDEXING (MODE, X, ADDR); \ - if (GET_CODE (X) == PLUS) \ - { if (GET_CODE (XEXP (X, 1)) == CONST_INT \ - && (TARGET_68020 || (unsigned) INTVAL (XEXP (X, 1)) + 0x80 < 0x100)) \ - { rtx go_temp = XEXP (X, 0); GO_IF_INDEXING (MODE, go_temp, ADDR); } \ - if (GET_CODE (XEXP (X, 0)) == CONST_INT \ - && (TARGET_68020 || (unsigned) INTVAL (XEXP (X, 0)) + 0x80 < 0x100)) \ - { rtx go_temp = XEXP (X, 1); GO_IF_INDEXING (MODE, go_temp, ADDR); } } } - - /* ColdFire/5200 does not allow HImode index registers. */ - #define LEGITIMATE_INDEX_REG_P(X, MODE) \ - ((GET_CODE (X) == REG && REG_MODE_OK_FOR_INDEX_P (X, MODE)) \ - || (! TARGET_COLDFIRE \ - && GET_CODE (X) == SIGN_EXTEND \ - && GET_CODE (XEXP (X, 0)) == REG \ - && GET_MODE (XEXP (X, 0)) == HImode \ - && REG_MODE_OK_FOR_INDEX_P (XEXP (X, 0), MODE)) \ - || (GET_CODE (X) == SUBREG \ - && GET_CODE (SUBREG_REG (X)) == REG \ - && REG_MODE_OK_FOR_INDEX_P (SUBREG_REG (X), MODE))) - - #define LEGITIMATE_INDEX_P(X, MODE) \ - (LEGITIMATE_INDEX_REG_P (X, MODE) \ - || ((TARGET_68020 || TARGET_COLDFIRE) && GET_CODE (X) == MULT \ - && LEGITIMATE_INDEX_REG_P (XEXP (X, 0), MODE) \ - && GET_CODE (XEXP (X, 1)) == CONST_INT \ - && (INTVAL (XEXP (X, 1)) == 2 \ - || INTVAL (XEXP (X, 1)) == 4 \ - || (INTVAL (XEXP (X, 1)) == 8 \ - && (TARGET_COLDFIRE_FPU || !TARGET_COLDFIRE))))) - - /* Coldfire FPU only accepts addressing modes 2-5 */ - #define GO_IF_COLDFIRE_FPU_LEGITIMATE_ADDRESS(MODE, X, ADDR) \ - { if (LEGITIMATE_BASE_REG_P (X) \ - || ((GET_CODE (X) == PRE_DEC || GET_CODE (X) == POST_INC) \ - && LEGITIMATE_BASE_REG_P (XEXP (X, 0))) \ - || ((GET_CODE (X) == PLUS) && LEGITIMATE_BASE_REG_P (XEXP (X, 0)) \ - && (GET_CODE (XEXP (X, 1)) == CONST_INT) \ - && ((((unsigned) INTVAL (XEXP (X, 1)) + 0x8000) < 0x10000)))) \ - goto ADDR;} - - /* If pic, we accept INDEX+LABEL, which is what do_tablejump makes. */ #define GO_IF_LEGITIMATE_ADDRESS(MODE, X, ADDR) \ ! { if (TARGET_COLDFIRE_FPU && (GET_MODE_CLASS (MODE) == MODE_FLOAT)) \ { \ ! GO_IF_COLDFIRE_FPU_LEGITIMATE_ADDRESS (MODE, X, ADDR); \ } \ ! else \ ! { \ ! GO_IF_NONINDEXED_ADDRESS (X, ADDR); \ ! GO_IF_INDEXED_ADDRESS (MODE, X, ADDR); \ ! if (flag_pic && MODE == CASE_VECTOR_MODE && GET_CODE (X) == PLUS \ ! && LEGITIMATE_INDEX_P (XEXP (X, 0), MODE) \ ! && GET_CODE (XEXP (X, 1)) == LABEL_REF) \ ! goto ADDR; \ ! }} /* Don't call memory_address_noforce for the address to fetch ! the switch offset. This address is ok as it stands (see above), but memory_address_noforce would alter it. */ #define PIC_CASE_VECTOR_ADDRESS(index) index \f --- 809,839 ---- && !m68k_illegitimate_symbolic_constant_p (X)) #ifndef REG_OK_STRICT ! #define REG_STRICT_P 0 #else ! #define REG_STRICT_P 1 #endif ! #define LEGITIMATE_PIC_OPERAND_P(X) \ ! (!symbolic_operand (X, VOIDmode) \ ! || (TARGET_PCREL && REG_STRICT_P)) #define REG_OK_FOR_BASE_P(X) \ ! m68k_legitimate_base_reg_p (X, REG_STRICT_P) #define REG_MODE_OK_FOR_INDEX_P(X, MODE) \ ! m68k_legitimate_index_reg_p (MODE, X, REG_STRICT_P) #define GO_IF_LEGITIMATE_ADDRESS(MODE, X, ADDR) \ ! do \ { \ ! if (m68k_legitimate_address_p (MODE, X, REG_STRICT_P)) \ ! goto ADDR; \ } \ ! while (0) /* Don't call memory_address_noforce for the address to fetch ! the switch offset. This address is ok as it stands, but memory_address_noforce would alter it. */ #define PIC_CASE_VECTOR_ADDRESS(index) index \f Index: gcc/config/m68k/m68k.c =================================================================== *** gcc/config/m68k/m68k.c 2007-01-09 15:02:08.000000000 +0000 --- gcc/config/m68k/m68k.c 2007-01-09 15:02:09.000000000 +0000 *************** struct m68k_frame *** 103,108 **** --- 103,129 ---- /* Current frame information calculated by m68k_compute_frame_layout(). */ static struct m68k_frame current_frame; + /* Structure describing an m68k address. + + If CODE is UNKNOWN, the address is BASE + INDEX * SCALE + OFFSET, + with null fields evaluating to 0. Here: + + - BASE satisfies m68k_legitimate_base_reg_p + - INDEX satisfies m68k_legitimate_index_reg_p + - OFFSET satisfies m68k_legitimate_constant_address_p + + INDEX is either HImode or SImode. The other fields are SImode. + + If CODE is PRE_DEC, the address is -(BASE). If CODE is POST_INC, + the address is (BASE)+. */ + struct m68k_address { + enum rtx_code code; + rtx base; + rtx index; + rtx offset; + int scale; + }; + static bool m68k_handle_option (size_t, const char *, int); static rtx find_addr_reg (rtx); static const char *singlemove_string (rtx *); *************** output_btst (rtx *operands, rtx countop, *** 1671,1676 **** --- 1692,1770 ---- return "btst %0,%1"; } \f + /* Return true if X is a legitimate base register. STRICT_P says + whether we need strict checking. */ + + bool + m68k_legitimate_base_reg_p (rtx x, bool strict_p) + { + /* Allow SUBREG everywhere we allow REG. This results in better code. */ + if (!strict_p && GET_CODE (x) == SUBREG) + x = SUBREG_REG (x); + + return (REG_P (x) + && (strict_p + ? REGNO_OK_FOR_BASE_P (REGNO (x)) + : !DATA_REGNO_P (REGNO (x)) && !FP_REGNO_P (REGNO (x)))); + } + + /* Return true if X is a legitimate index register when accessing a + value of mode MODE. STRICT_P says whether we need strict checking. */ + + bool + m68k_legitimate_index_reg_p (enum machine_mode mode, rtx x, bool strict_p) + { + if (!strict_p && GET_CODE (x) == SUBREG) + x = SUBREG_REG (x); + + return (REG_P (x) + && (strict_p + ? REGNO_MODE_OK_FOR_INDEX_P (REGNO (x), mode) + : MODE_OK_FOR_INDEX_P (mode) && !FP_REGNO_P (REGNO (x)))); + } + + /* Return true if X is a legitimate index expression for a + (d8,An,Xn) or (bd,An,Xn) addressing mode, given that the address + is used to access a value of mode MODE. Fill in the INDEX and + SCALE fields of ADDRESS if so. STRICT_P says whether we + need strict checking. */ + + static bool + m68k_decompose_index (enum machine_mode mode, rtx x, bool strict_p, + struct m68k_address *address) + { + int scale; + + /* Check for a scale factor. */ + scale = 1; + if ((TARGET_68020 || TARGET_COLDFIRE) + && GET_CODE (x) == MULT + && GET_CODE (XEXP (x, 1)) == CONST_INT + && (INTVAL (XEXP (x, 1)) == 2 + || INTVAL (XEXP (x, 1)) == 4 + || (INTVAL (XEXP (x, 1)) == 8 + && (TARGET_COLDFIRE_FPU || !TARGET_COLDFIRE)))) + { + scale = INTVAL (XEXP (x, 1)); + x = XEXP (x, 0); + } + + /* Check for a word extension. */ + if (!TARGET_COLDFIRE + && GET_CODE (x) == SIGN_EXTEND + && GET_MODE (XEXP (x, 0)) == HImode) + x = XEXP (x, 0); + + if (m68k_legitimate_index_reg_p (mode, x, strict_p)) + { + address->scale = scale; + address->index = x; + return true; + } + + return false; + } + /* Return true if X is an illegitimate symbolic constant. */ bool *************** m68k_illegitimate_symbolic_constant_p (r *** 1688,1693 **** --- 1782,2032 ---- return false; } + /* Return true if X is a legitimate constant address that can reach + bytes in the range [X, X + REACH). STRICT_P says whether we need + strict checking. */ + + static bool + m68k_legitimate_constant_address_p (rtx x, unsigned int reach, bool strict_p) + { + rtx base, offset; + + if (!CONSTANT_ADDRESS_P (x)) + return false; + + if (flag_pic + && !(strict_p && TARGET_PCREL) + && symbolic_operand (x, VOIDmode)) + return false; + + if (M68K_OFFSETS_MUST_BE_WITHIN_SECTIONS_P && reach > 1) + { + split_const (x, &base, &offset); + if (GET_CODE (base) == SYMBOL_REF + && !offset_within_block_p (base, INTVAL (offset) + reach - 1)) + return false; + } + + return true; + } + + /* Return true if X is a LABEL_REF for a jump table. Assume that unplaced + labels will become jump tables. */ + + static bool + m68k_jump_table_ref_p (rtx x) + { + if (GET_CODE (x) != LABEL_REF) + return false; + + x = XEXP (x, 0); + if (!NEXT_INSN (x) && !PREV_INSN (x)) + return true; + + x = next_nonnote_insn (x); + return x && JUMP_TABLE_DATA_P (x); + } + + /* Return true if X is a legitimate address for values of mode MODE. + STRICT_P says whether strict checking is needed. If the address + is valid, describe its components in *ADDRESS. */ + + static bool + m68k_decompose_address (enum machine_mode mode, rtx x, + bool strict_p, struct m68k_address *address) + { + unsigned int reach; + + memset (address, 0, sizeof (*address)); + + if (mode == BLKmode) + reach = 1; + else + reach = GET_MODE_SIZE (mode); + + /* Check for (An) (mode 2). */ + if (m68k_legitimate_base_reg_p (x, strict_p)) + { + address->base = x; + return true; + } + + /* Check for -(An) and (An)+ (modes 3 and 4). */ + if ((GET_CODE (x) == PRE_DEC || GET_CODE (x) == POST_INC) + && m68k_legitimate_base_reg_p (XEXP (x, 0), strict_p)) + { + address->code = GET_CODE (x); + address->base = XEXP (x, 0); + return true; + } + + /* Check for (d16,An) (mode 5). */ + if (GET_CODE (x) == PLUS + && GET_CODE (XEXP (x, 1)) == CONST_INT + && IN_RANGE (INTVAL (XEXP (x, 1)), -0x8000, 0x8000 - reach) + && m68k_legitimate_base_reg_p (XEXP (x, 0), strict_p)) + { + address->base = XEXP (x, 0); + address->offset = XEXP (x, 1); + return true; + } + + /* Check for GOT loads. These are (bd,An,Xn) addresses if + TARGET_68020 && flag_pic == 2, otherwise they are (d16,An) + addresses. */ + if (flag_pic + && GET_CODE (x) == PLUS + && XEXP (x, 0) == pic_offset_table_rtx + && (GET_CODE (XEXP (x, 1)) == SYMBOL_REF + || GET_CODE (XEXP (x, 1)) == LABEL_REF)) + { + address->base = XEXP (x, 0); + address->offset = XEXP (x, 1); + return true; + } + + /* The ColdFire FPU only accepts addressing modes 2-5. */ + if (TARGET_COLDFIRE_FPU && GET_MODE_CLASS (mode) == MODE_FLOAT) + return false; + + /* Check for (xxx).w and (xxx).l. Also, in the TARGET_PCREL case, + check for (d16,PC) or (bd,PC,Xn) with a suppressed index register. + All these modes are variations of mode 7. */ + if (m68k_legitimate_constant_address_p (x, reach, strict_p)) + { + address->offset = x; + return true; + } + + /* Check for (d8,PC,Xn), a mode 7 form. This case is needed for + tablejumps. + + ??? do_tablejump creates these addresses before placing the target + label, so we have to assume that unplaced labels are jump table + references. It seems unlikely that we would ever generate indexed + accesses to unplaced labels in other cases. */ + if (GET_CODE (x) == PLUS + && m68k_jump_table_ref_p (XEXP (x, 1)) + && m68k_decompose_index (mode, XEXP (x, 0), strict_p, address)) + { + address->offset = XEXP (x, 1); + return true; + } + + /* Everything hereafter deals with (d8,An,Xn.SIZE*SCALE) or + (bd,An,Xn.SIZE*SCALE) addresses. */ + + if (TARGET_68020) + { + /* Check for a nonzero base displacement. */ + if (GET_CODE (x) == PLUS + && m68k_legitimate_constant_address_p (XEXP (x, 1), reach, strict_p)) + { + address->offset = XEXP (x, 1); + x = XEXP (x, 0); + } + + /* Check for a suppressed index register. */ + if (m68k_legitimate_base_reg_p (x, strict_p)) + { + address->base = x; + return true; + } + + /* Check for a suppressed base register. Do not allow this case + for non-symbolic offsets as it effectively gives gcc freedom + to treat data registers as base registers, which can generate + worse code. */ + if (address->offset + && symbolic_operand (address->offset, VOIDmode) + && m68k_decompose_index (mode, x, strict_p, address)) + return true; + } + else + { + /* Check for a nonzero base displacement. */ + if (GET_CODE (x) == PLUS + && GET_CODE (XEXP (x, 1)) == CONST_INT + && IN_RANGE (INTVAL (XEXP (x, 1)), -0x80, 0x80 - reach)) + { + address->offset = XEXP (x, 1); + x = XEXP (x, 0); + } + } + + /* We now expect the sum of a base and an index. */ + if (GET_CODE (x) == PLUS) + { + if (m68k_legitimate_base_reg_p (XEXP (x, 0), strict_p) + && m68k_decompose_index (mode, XEXP (x, 1), strict_p, address)) + { + address->base = XEXP (x, 0); + return true; + } + + if (m68k_legitimate_base_reg_p (XEXP (x, 1), strict_p) + && m68k_decompose_index (mode, XEXP (x, 0), strict_p, address)) + { + address->base = XEXP (x, 1); + return true; + } + } + return false; + } + + /* Return true if X is a legitimate address for values of mode MODE. + STRICT_P says whether strict checking is needed. */ + + bool + m68k_legitimate_address_p (enum machine_mode mode, rtx x, bool strict_p) + { + struct m68k_address address; + + return m68k_decompose_address (mode, x, strict_p, &address); + } + + /* Return true if X is a memory, describing its address in ADDRESS if so. + Apply strict checking if called during or after reload. */ + + static bool + m68k_legitimate_mem_p (rtx x, struct m68k_address *address) + { + return (MEM_P (x) + && m68k_decompose_address (GET_MODE (x), XEXP (x, 0), + reload_in_progress || reload_completed, + address)); + } + + /* Return true if X matches the 'Q' constraint. It must be a memory + with a base address and no constant offset or index. */ + + bool + m68k_matches_q_p (rtx x) + { + struct m68k_address address; + + return (m68k_legitimate_mem_p (x, &address) + && address.code == UNKNOWN + && address.base + && !address.offset + && !address.index); + } + + /* Return true if X matches the 'U' constraint. It must be a base address + with a constant offset and no index. */ + + bool + m68k_matches_u_p (rtx x) + { + struct m68k_address address; + + return (m68k_legitimate_mem_p (x, &address) + && address.code == UNKNOWN + && address.base + && address.offset + && !address.index); + } + /* Legitimize PIC addresses. If the address is already position-independent, we return ORIG. Newly generated position-independent addresses go to REG. If we need more *************** print_operand (FILE *file, rtx op, int l *** 3243,3507 **** offset is output in word mode (e.g. movel a5@(_foo:w), a0). When generating -fPIC code the offset is output in long mode (e.g. movel a5@(_foo:l), a0) */ - #if MOTOROLA - # define ASM_OUTPUT_CASE_FETCH(file, labelno, regname) \ - asm_fprintf (file, "%LL%d-%LLI%d.b(%Rpc,%s.", labelno, labelno, regname) - #else /* !MOTOROLA */ - # define ASM_OUTPUT_CASE_FETCH(file, labelno, regname) \ - asm_fprintf (file, "%Rpc@(%LL%d-%LLI%d-2:b,%s:", labelno, labelno, regname) - #endif /* !MOTOROLA */ - void print_operand_address (FILE *file, rtx addr) { ! register rtx reg1, reg2, breg, ireg; ! rtx offset; ! switch (GET_CODE (addr)) ! { ! case REG: ! fprintf (file, MOTOROLA ? "(%s)" : "%s@", M68K_REGNAME (REGNO (addr))); ! break; ! case PRE_DEC: ! fprintf (file, MOTOROLA ? "-(%s)" : "%s@-", ! M68K_REGNAME (REGNO (XEXP (addr, 0)))); ! break; ! case POST_INC: ! fprintf (file, MOTOROLA ? "(%s)+" : "%s@+", ! M68K_REGNAME (REGNO (XEXP (addr, 0)))); ! break; ! case PLUS: ! reg1 = reg2 = ireg = breg = offset = 0; ! if (CONSTANT_ADDRESS_P (XEXP (addr, 0))) ! { ! offset = XEXP (addr, 0); ! addr = XEXP (addr, 1); ! } ! else if (CONSTANT_ADDRESS_P (XEXP (addr, 1))) ! { ! offset = XEXP (addr, 1); ! addr = XEXP (addr, 0); ! } ! if (GET_CODE (addr) != PLUS) ! { ! ; ! } ! else if (GET_CODE (XEXP (addr, 0)) == SIGN_EXTEND) ! { ! reg1 = XEXP (addr, 0); ! addr = XEXP (addr, 1); ! } ! else if (GET_CODE (XEXP (addr, 1)) == SIGN_EXTEND) ! { ! reg1 = XEXP (addr, 1); ! addr = XEXP (addr, 0); ! } ! else if (GET_CODE (XEXP (addr, 0)) == MULT) ! { ! reg1 = XEXP (addr, 0); ! addr = XEXP (addr, 1); ! } ! else if (GET_CODE (XEXP (addr, 1)) == MULT) ! { ! reg1 = XEXP (addr, 1); ! addr = XEXP (addr, 0); ! } ! else if (GET_CODE (XEXP (addr, 0)) == REG) ! { ! reg1 = XEXP (addr, 0); ! addr = XEXP (addr, 1); ! } ! else if (GET_CODE (XEXP (addr, 1)) == REG) ! { ! reg1 = XEXP (addr, 1); ! addr = XEXP (addr, 0); ! } ! if (GET_CODE (addr) == REG || GET_CODE (addr) == MULT ! || GET_CODE (addr) == SIGN_EXTEND) ! { ! if (reg1 == 0) ! reg1 = addr; else ! reg2 = addr; ! addr = 0; ! } ! #if 0 /* for OLD_INDEXING */ ! else if (GET_CODE (addr) == PLUS) ! { ! if (GET_CODE (XEXP (addr, 0)) == REG) ! { ! reg2 = XEXP (addr, 0); ! addr = XEXP (addr, 1); ! } ! else if (GET_CODE (XEXP (addr, 1)) == REG) ! { ! reg2 = XEXP (addr, 1); ! addr = XEXP (addr, 0); ! } } ! #endif ! if (offset != 0) ! { ! gcc_assert (!addr); ! addr = offset; ! } ! if ((reg1 && (GET_CODE (reg1) == SIGN_EXTEND ! || GET_CODE (reg1) == MULT)) ! || (reg2 != 0 && REGNO_OK_FOR_BASE_P (REGNO (reg2)))) ! { ! breg = reg2; ! ireg = reg1; ! } ! else if (reg1 != 0 && REGNO_OK_FOR_BASE_P (REGNO (reg1))) { ! breg = reg1; ! ireg = reg2; } ! if (ireg != 0 && breg == 0 && GET_CODE (addr) == LABEL_REF ! && ! (flag_pic && ireg == pic_offset_table_rtx)) { ! int scale = 1; ! if (GET_CODE (ireg) == MULT) ! { ! scale = INTVAL (XEXP (ireg, 1)); ! ireg = XEXP (ireg, 0); ! } ! if (GET_CODE (ireg) == SIGN_EXTEND) { ! ASM_OUTPUT_CASE_FETCH (file, ! CODE_LABEL_NUMBER (XEXP (addr, 0)), ! M68K_REGNAME (REGNO (XEXP (ireg, 0)))); ! fprintf (file, "w"); } else ! { ! ASM_OUTPUT_CASE_FETCH (file, ! CODE_LABEL_NUMBER (XEXP (addr, 0)), ! M68K_REGNAME (REGNO (ireg))); ! fprintf (file, "l"); ! } ! if (scale != 1) ! fprintf (file, MOTOROLA ? "*%d" : ":%d", scale); ! putc (')', file); ! break; } ! if (breg != 0 && ireg == 0 && GET_CODE (addr) == LABEL_REF ! && ! (flag_pic && breg == pic_offset_table_rtx)) { ! ASM_OUTPUT_CASE_FETCH (file, ! CODE_LABEL_NUMBER (XEXP (addr, 0)), ! M68K_REGNAME (REGNO (breg))); ! fprintf (file, "l)"); ! break; ! } ! if (ireg != 0 || breg != 0) ! { ! int scale = 1; ! ! gcc_assert (breg); ! gcc_assert (flag_pic || !addr || GET_CODE (addr) != LABEL_REF); ! ! if (MOTOROLA) { ! if (addr != 0) { ! output_addr_const (file, addr); ! if (flag_pic && (breg == pic_offset_table_rtx)) { fprintf (file, "@GOT"); ! if (flag_pic == 1) fprintf (file, ".w"); } } ! fprintf (file, "(%s", M68K_REGNAME (REGNO (breg))); ! if (ireg != 0) ! putc (',', file); } ! else /* !MOTOROLA */ ! { ! fprintf (file, "%s@(", M68K_REGNAME (REGNO (breg))); ! if (addr != 0) ! { ! output_addr_const (file, addr); ! if (breg == pic_offset_table_rtx) ! switch (flag_pic) ! { ! case 1: ! fprintf (file, ":w"); ! break; ! case 2: ! fprintf (file, ":l"); ! break; ! default: ! break; ! } ! if (ireg != 0) ! putc (',', file); ! } ! } /* !MOTOROLA */ ! if (ireg != 0 && GET_CODE (ireg) == MULT) { ! scale = INTVAL (XEXP (ireg, 1)); ! ireg = XEXP (ireg, 0); } - if (ireg != 0 && GET_CODE (ireg) == SIGN_EXTEND) - fprintf (file, MOTOROLA ? "%s.w" : "%s:w", - M68K_REGNAME (REGNO (XEXP (ireg, 0)))); - else if (ireg != 0) - fprintf (file, MOTOROLA ? "%s.l" : "%s:l", - M68K_REGNAME (REGNO (ireg))); - if (scale != 1) - fprintf (file, MOTOROLA ? "*%d" : ":%d", scale); putc (')', file); - break; - } - else if (reg1 != 0 && GET_CODE (addr) == LABEL_REF - && ! (flag_pic && reg1 == pic_offset_table_rtx)) - { - ASM_OUTPUT_CASE_FETCH (file, - CODE_LABEL_NUMBER (XEXP (addr, 0)), - M68K_REGNAME (REGNO (reg1))); - fprintf (file, "l)"); - break; - } - /* FALL-THROUGH (is this really what we want?) */ - default: - if (GET_CODE (addr) == CONST_INT - && INTVAL (addr) < 0x8000 - && INTVAL (addr) >= -0x8000) - { - fprintf (file, MOTOROLA ? "%d.w" : "%d:w", (int) INTVAL (addr)); - } - else if (GET_CODE (addr) == CONST_INT) - { - fprintf (file, HOST_WIDE_INT_PRINT_DEC, INTVAL (addr)); } ! else if (TARGET_PCREL) { ! fputc ('(', file); ! output_addr_const (file, addr); ! if (flag_pic == 1) ! asm_fprintf (file, ":w,%Rpc)"); else - asm_fprintf (file, ":l,%Rpc)"); - } - else - { - /* Special case for SYMBOL_REF if the symbol name ends in - `.<letter>', this can be mistaken as a size suffix. Put - the name in parentheses. */ - if (GET_CODE (addr) == SYMBOL_REF - && strlen (XSTR (addr, 0)) > 2 - && XSTR (addr, 0)[strlen (XSTR (addr, 0)) - 2] == '.') { ! putc ('(', file); ! output_addr_const (file, addr); putc (')', file); } - else - output_addr_const (file, addr); } - break; } } \f --- 3582,3723 ---- offset is output in word mode (e.g. movel a5@(_foo:w), a0). When generating -fPIC code the offset is output in long mode (e.g. movel a5@(_foo:l), a0) */ void print_operand_address (FILE *file, rtx addr) { ! struct m68k_address address; ! if (!m68k_decompose_address (QImode, addr, true, &address)) ! gcc_unreachable (); ! ! if (address.code == PRE_DEC) ! fprintf (file, MOTOROLA ? "-(%s)" : "%s@-", ! M68K_REGNAME (REGNO (address.base))); ! else if (address.code == POST_INC) ! fprintf (file, MOTOROLA ? "(%s)+" : "%s@+", ! M68K_REGNAME (REGNO (address.base))); ! else if (!address.base && !address.index) ! { ! /* A constant address. */ ! gcc_assert (address.offset == addr); ! if (GET_CODE (addr) == CONST_INT) ! { ! /* (xxx).w or (xxx).l. */ ! if (IN_RANGE (INTVAL (addr), -0x8000, 0x7fff)) ! fprintf (file, MOTOROLA ? "%d.w" : "%d:w", (int) INTVAL (addr)); else ! fprintf (file, HOST_WIDE_INT_PRINT_DEC, INTVAL (addr)); } ! else if (TARGET_PCREL) { ! /* (d16,PC) or (bd,PC,Xn) (with suppressed index register). */ ! fputc ('(', file); ! output_addr_const (file, addr); ! asm_fprintf (file, flag_pic == 1 ? ":w,%Rpc)" : ":l,%Rpc)"); } ! else { ! /* (xxx).l. We need a special case for SYMBOL_REF if the symbol ! name ends in `.<letter>', as the last 2 characters can be ! mistaken as a size suffix. Put the name in parentheses. */ ! if (GET_CODE (addr) == SYMBOL_REF ! && strlen (XSTR (addr, 0)) > 2 ! && XSTR (addr, 0)[strlen (XSTR (addr, 0)) - 2] == '.') { ! putc ('(', file); ! output_addr_const (file, addr); ! putc (')', file); } else ! output_addr_const (file, addr); } ! } ! else ! { ! int labelno; ! ! /* If ADDR is a (d8,pc,Xn) address, this is the number of the ! label being acceesed, otherwise it is -1. */ ! labelno = (address.offset ! && !address.base ! && GET_CODE (address.offset) == LABEL_REF ! ? CODE_LABEL_NUMBER (XEXP (address.offset, 0)) ! : -1); ! if (MOTOROLA) { ! /* Print the "offset(base" component. */ ! if (labelno >= 0) ! asm_fprintf (file, "%LL%d-%LLI%d.b(%Rpc,", labelno, labelno); ! else { ! if (address.offset) { ! output_addr_const (file, address.offset); ! if (flag_pic && address.base == pic_offset_table_rtx) { fprintf (file, "@GOT"); ! if (flag_pic == 1 && TARGET_68020) fprintf (file, ".w"); } } ! putc ('(', file); ! if (address.base) ! fputs (M68K_REGNAME (REGNO (address.base)), file); } ! /* Print the ",index" component, if any. */ ! if (address.index) { ! if (address.base) ! putc (',', file); ! fprintf (file, "%s.%c", ! M68K_REGNAME (REGNO (address.index)), ! GET_MODE (address.index) == HImode ? 'w' : 'l'); ! if (address.scale != 1) ! fprintf (file, "*%d", address.scale); } putc (')', file); } ! else /* !MOTOROLA */ { ! if (!address.offset && !address.index) ! fprintf (file, "%s@", M68K_REGNAME (REGNO (address.base))); else { ! /* Print the "base@(offset" component. */ ! if (labelno >= 0) ! asm_fprintf (file, "%Rpc@(%LL%d-%LLI%d-2:b", labelno, labelno); ! else ! { ! if (address.base) ! fputs (M68K_REGNAME (REGNO (address.base)), file); ! fprintf (file, "@("); ! if (address.offset) ! { ! output_addr_const (file, address.offset); ! if (address.base == pic_offset_table_rtx && TARGET_68020) ! switch (flag_pic) ! { ! case 1: ! fprintf (file, ":w"); break; ! case 2: ! fprintf (file, ":l"); break; ! default: ! break; ! } ! } ! } ! /* Print the ",index" component, if any. */ ! if (address.index) ! { ! fprintf (file, ",%s:%c", ! M68K_REGNAME (REGNO (address.index)), ! GET_MODE (address.index) == HImode ? 'w' : 'l'); ! if (address.scale != 1) ! fprintf (file, ":%d", address.scale); ! } putc (')', file); } } } } \f ^ permalink raw reply [flat|nested] 280+ messages in thread
* [middle-end, ColdFire 28/63] Change the canonical NaN representation 2007-01-10 11:32 ` [ColdFire 27/63] Addressing mode changes and fixes Richard Sandiford @ 2007-01-10 11:34 ` Richard Sandiford 2007-01-10 11:35 ` [ColdFire 29/63] Fix a movdf bug Richard Sandiford 2007-01-11 5:32 ` [middle-end, ColdFire 28/63] Change the canonical NaN representation Roger Sayle 0 siblings, 2 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 11:34 UTC (permalink / raw) To: gcc-patches The NaNs generated by __builtin_nan() have a different significand to the ones created by the ColdFire FPU. __builtin_nan() sets the msb (to indicate a quiet NaN) and clears the rest, whereas the FPU sets every bit. MIPS diverges from the norm in a different way. On MIPS, quiet NaNs have the msb clear and signalling NaNs have the msb set. However, in a canonical NaN, all other bits of significand will be set. So we have the following canonical significands for quiet NaNs: Normal: 10000000.... MIPS: 01111111.... ColdFire: 11111111.... The problem is that both of the MIPS divergences (the inverted sense of the msb, and canonical form of the lsbs) are controlled by a single real_format flag. This patch splits it into two and creates new real_formats for ColdFire. It fixes the ieee/copysign test. Note that the new formats are only chosen when using the ColdFire FPU. We still want to use normal NaNs for soft float, at least until the ColdFire libm libraries use the FPU encoding (if that ever happens). The 68881 uses the same NaN encoding as ColdFire. I don't know if we want to do the same thing there or not; Andreas didn't seem too keen when I mentioned the problem in a glibc context. Richard gcc/ * real.h (real_format): Add a canonical_nan_lsbs_set field. (coldfire_single_format): Declare. (coldfire_double_format): Likewise. * real.c (encode_ieee_single): Use canonical_nan_lsbs_set instead of qnan_msb_set to determine the lower bits of a canonical NaN significand. (encode_ieee_double): Likewise. (encode_ieee_quad): Likewise. (ieee_single_format): Initialize canonical_nan_lsbs_set. (mips_single_format): Likewise. (ieee_double_format): Likewise. (mips_double_format): Likewise. (ieee_extended_motorola_format): Likewise. (ieee_extended_intel_96_format): Likewise. (ieee_extended_intel_128_format): Likewise. (ieee_extended_intel_96_round_53_format): Likewise. (ibm_extended_format): Likewise. (mips_extended_format): Likewise. (ieee_quad_format): Likewise. (mips_quad_format): Likewise. (vax_f_format): Likewise. (vax_d_format): Likewise. (vax_g_format): Likewise. (i370_single_format): Likewise. (i370_double_format): Likewise. (decimal_single_format): Likewise. (decimal_double_format): Likewise. (decimal_quad_format): Likewise. (c4x_single_format): Likewise. (c4x_extended_format): Likewise. (real_internal_format): Likewise. (coldfire_single_format): New real_format. (coldfire_double_format): Likewise. * config/pdp11/pdp11.c (pdp11_f_format): Initialize canonical_nan_lsbs_set. (pdp11_d_format): Likewise. * config/m68k/m68k.c (override_options): Override REAL_FORMAT_MODE if TARGET_COLDFIRE_CPU. Index: gcc/real.h =================================================================== --- gcc/real.h 2007-01-09 13:18:12.000000000 +0000 +++ gcc/real.h 2007-01-09 15:02:10.000000000 +0000 @@ -155,6 +155,7 @@ struct real_format bool has_denorm; bool has_signed_zero; bool qnan_msb_set; + bool canonical_nan_lsbs_set; }; @@ -255,8 +256,10 @@ extern unsigned int real_hash (const REA /* Target formats defined in real.c. */ extern const struct real_format ieee_single_format; extern const struct real_format mips_single_format; +extern const struct real_format coldfire_single_format; extern const struct real_format ieee_double_format; extern const struct real_format mips_double_format; +extern const struct real_format coldfire_double_format; extern const struct real_format ieee_extended_motorola_format; extern const struct real_format ieee_extended_intel_96_format; extern const struct real_format ieee_extended_intel_96_round_53_format; Index: gcc/real.c =================================================================== --- gcc/real.c 2007-01-09 13:18:12.000000000 +0000 +++ gcc/real.c 2007-01-09 15:02:10.000000000 +0000 @@ -2681,18 +2681,12 @@ encode_ieee_single (const struct real_fo if (fmt->has_nans) { if (r->canonical) - sig = 0; + sig = (fmt->canonical_nan_lsbs_set ? (1 << 22) - 1 : 0); if (r->signalling == fmt->qnan_msb_set) sig &= ~(1 << 22); else sig |= 1 << 22; - /* We overload qnan_msb_set here: it's only clear for - mips_ieee_single, which wants all mantissa bits but the - quiet/signalling one set in canonical NaNs (at least - Quiet ones). */ - if (r->canonical && !fmt->qnan_msb_set) - sig |= (1 << 22) - 1; - else if (sig == 0) + if (sig == 0) sig = 1 << 21; image |= 255 << 23; @@ -2787,7 +2781,8 @@ const struct real_format ieee_single_for true, true, true, - true + true, + false }; const struct real_format mips_single_format = @@ -2806,9 +2801,29 @@ const struct real_format mips_single_for true, true, true, - false + false, + true }; +const struct real_format coldfire_single_format = + { + encode_ieee_single, + decode_ieee_single, + 2, + 1, + 24, + 24, + -125, + 128, + 31, + 31, + true, + true, + true, + true, + true, + true + }; \f /* IEEE double-precision format. */ @@ -2860,21 +2875,23 @@ encode_ieee_double (const struct real_fo if (fmt->has_nans) { if (r->canonical) - sig_hi = sig_lo = 0; + { + if (fmt->canonical_nan_lsbs_set) + { + sig_hi = (1 << 19) - 1; + sig_lo = 0xffffffff; + } + else + { + sig_hi = 0; + sig_lo = 0; + } + } if (r->signalling == fmt->qnan_msb_set) sig_hi &= ~(1 << 19); else sig_hi |= 1 << 19; - /* We overload qnan_msb_set here: it's only clear for - mips_ieee_single, which wants all mantissa bits but the - quiet/signalling one set in canonical NaNs (at least - Quiet ones). */ - if (r->canonical && !fmt->qnan_msb_set) - { - sig_hi |= (1 << 19) - 1; - sig_lo = 0xffffffff; - } - else if (sig_hi == 0 && sig_lo == 0) + if (sig_hi == 0 && sig_lo == 0) sig_hi = 1 << 18; image_hi |= 2047 << 20; @@ -3012,7 +3029,8 @@ const struct real_format ieee_double_for true, true, true, - true + true, + false }; const struct real_format mips_double_format = @@ -3031,9 +3049,29 @@ const struct real_format mips_double_for true, true, true, - false + false, + true }; +const struct real_format coldfire_double_format = + { + encode_ieee_double, + decode_ieee_double, + 2, + 1, + 53, + 53, + -1021, + 1024, + 63, + 63, + true, + true, + true, + true, + true, + true + }; \f /* IEEE extended real format. This comes in three flavors: Intel's as a 12 byte image, Intel's as a 16 byte image, and Motorola's. Intel @@ -3361,7 +3399,8 @@ const struct real_format ieee_extended_m true, true, true, - true + true, + false }; const struct real_format ieee_extended_intel_96_format = @@ -3380,7 +3419,8 @@ const struct real_format ieee_extended_i true, true, true, - true + true, + false }; const struct real_format ieee_extended_intel_128_format = @@ -3399,7 +3439,8 @@ const struct real_format ieee_extended_i true, true, true, - true + true, + false }; /* The following caters to i386 systems that set the rounding precision @@ -3420,7 +3461,8 @@ const struct real_format ieee_extended_i true, true, true, - true + true, + false }; \f /* IBM 128-bit extended precision format: a pair of IEEE double precision @@ -3506,7 +3548,8 @@ const struct real_format ibm_extended_fo true, true, true, - true + true, + false }; const struct real_format mips_extended_format = @@ -3525,7 +3568,8 @@ const struct real_format mips_extended_f true, true, true, - false + false, + true }; \f @@ -3575,8 +3619,11 @@ encode_ieee_quad (const struct real_form if (r->canonical) { - /* Don't use bits from the significand. The - initialization above is right. */ + if (fmt->canonical_nan_lsbs_set) + { + image3 |= 0x7fff; + image2 = image1 = image0 = 0xffffffff; + } } else if (HOST_BITS_PER_LONG == 32) { @@ -3598,16 +3645,7 @@ encode_ieee_quad (const struct real_form image3 &= ~0x8000; else image3 |= 0x8000; - /* We overload qnan_msb_set here: it's only clear for - mips_ieee_single, which wants all mantissa bits but the - quiet/signalling one set in canonical NaNs (at least - Quiet ones). */ - if (r->canonical && !fmt->qnan_msb_set) - { - image3 |= 0x7fff; - image2 = image1 = image0 = 0xffffffff; - } - else if (((image3 & 0xffff) | image2 | image1 | image0) == 0) + if (((image3 & 0xffff) | image2 | image1 | image0) == 0) image3 |= 0x4000; } else @@ -3792,7 +3830,8 @@ const struct real_format ieee_quad_forma true, true, true, - true + true, + false }; const struct real_format mips_quad_format = @@ -3811,7 +3850,8 @@ const struct real_format mips_quad_forma true, true, true, - false + false, + true }; \f /* Descriptions of VAX floating point formats can be found beginning at @@ -4109,6 +4149,7 @@ const struct real_format vax_f_format = false, false, false, + false, false }; @@ -4128,6 +4169,7 @@ const struct real_format vax_d_format = false, false, false, + false, false }; @@ -4147,6 +4189,7 @@ const struct real_format vax_g_format = false, false, false, + false, false }; \f @@ -4323,6 +4366,7 @@ const struct real_format i370_single_for false, false, /* ??? The encoding does allow for "unnormals". */ false, /* ??? The encoding does allow for "unnormals". */ + false, false }; @@ -4342,6 +4386,7 @@ const struct real_format i370_double_for false, false, /* ??? The encoding does allow for "unnormals". */ false, /* ??? The encoding does allow for "unnormals". */ + false, false }; \f @@ -4416,7 +4461,8 @@ const struct real_format decimal_single_ true, true, true, - true + true, + false }; /* Double precision decimal floating point (IEEE 754R). */ @@ -4436,7 +4482,8 @@ const struct real_format decimal_double_ true, true, true, - true + true, + false }; /* Quad precision decimal floating point (IEEE 754R). */ @@ -4456,7 +4503,8 @@ const struct real_format decimal_quad_fo true, true, true, - true + true, + false }; \f /* The "twos-complement" c4x format is officially defined as @@ -4665,6 +4713,7 @@ const struct real_format c4x_single_form false, false, false, + false, false }; @@ -4684,6 +4733,7 @@ const struct real_format c4x_extended_fo false, false, false, + false, false }; @@ -4728,7 +4778,8 @@ const struct real_format real_internal_f true, false, true, - true + true, + false }; \f /* Calculate the square root of X in mode MODE, and store the result Index: gcc/config/pdp11/pdp11.c =================================================================== --- gcc/config/pdp11/pdp11.c 2007-01-09 13:18:12.000000000 +0000 +++ gcc/config/pdp11/pdp11.c 2007-01-09 15:02:10.000000000 +0000 @@ -78,6 +78,7 @@ const struct real_format pdp11_f_format false, false, false, + false, false }; @@ -96,6 +97,7 @@ const struct real_format pdp11_d_format false, false, false, + false, false }; Index: gcc/config/m68k/m68k.c =================================================================== --- gcc/config/m68k/m68k.c 2007-01-09 15:02:09.000000000 +0000 +++ gcc/config/m68k/m68k.c 2007-01-09 15:02:10.000000000 +0000 @@ -536,6 +536,12 @@ override_options (void) : (m68k_cpu_flags & FL_COLDFIRE) != 0 ? FPUTYPE_COLDFIRE : FPUTYPE_68881); + if (TARGET_COLDFIRE_FPU) + { + REAL_MODE_FORMAT (SFmode) = &coldfire_single_format; + REAL_MODE_FORMAT (DFmode) = &coldfire_double_format; + } + /* Sanity check to ensure that msep-data and mid-sahred-library are not * both specified together. Doing so simply doesn't make sense. */ ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 29/63] Fix a movdf bug 2007-01-10 11:34 ` [middle-end, ColdFire 28/63] Change the canonical NaN representation Richard Sandiford @ 2007-01-10 11:35 ` Richard Sandiford 2007-01-10 11:38 ` [ColdFire 30/63] Fix rounding for ColdFire FPUs Richard Sandiford 2007-01-10 18:44 ` [ColdFire 29/63] Fix a movdf bug Jeffrey Law 2007-01-11 5:32 ` [middle-end, ColdFire 28/63] Change the canonical NaN representation Roger Sayle 1 sibling, 2 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 11:35 UTC (permalink / raw) To: gcc-patches The r<-r case in movdf_cf_hard moves the individual registers in a fixed order: case 4: return "move%.l %1,%0;move%.l %R1,%R0"; It therefore doesn't handle overlap such as (reg:DF d1) <- (reg:DF d0). output_move_double knows how to handle reg<-reg moves properly, and we already use it for r<-m and m<-r. So the fix is trivial: use it for r<-r too. Richard gcc/ * config/m68k/m68k.md (movdf_cf_hard): Use output_move_double for GPR<-GPR moves. Index: gcc/config/m68k/m68k.md =================================================================== --- gcc/config/m68k/m68k.md 2007-01-09 15:02:08.000000000 +0000 +++ gcc/config/m68k/m68k.md 2007-01-09 15:02:11.000000000 +0000 @@ -1025,9 +1025,7 @@ (define_insn "movdf_cf_hard" return "fmove%.d %1,%-;move%.l %+,%0;move%.l %+,%R0"; case 3: return "move%.l %R1,%-;move%.l %1,%-;f%&move%.d %+,%0"; - case 4: - return "move%.l %1,%0;move%.l %R1,%R0"; - case 5: case 6: + case 4: case 5: case 6: return output_move_double (operands); case 7: REAL_VALUE_FROM_CONST_DOUBLE (r, operands[1]); ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 30/63] Fix rounding for ColdFire FPUs 2007-01-10 11:35 ` [ColdFire 29/63] Fix a movdf bug Richard Sandiford @ 2007-01-10 11:38 ` Richard Sandiford 2007-01-10 11:39 ` [ColdFire 31/63] Fix rounding problems in fpgnulib.c Richard Sandiford 2007-01-11 17:35 ` [ColdFire 30/63] Fix rounding for ColdFire FPUs Jeffrey Law 2007-01-10 18:44 ` [ColdFire 29/63] Fix a movdf bug Jeffrey Law 1 sibling, 2 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 11:38 UTC (permalink / raw) To: gcc-patches The ColdFire SFmode addition and subtraction patterns do not round the result to single precision. This caused a miscompilation of some maths routines, which in turn led to odd results like rintf(-4.5f) == -4.5f. I'll need to step back a bit before describing how I think this mistake was made. The original 68881 was like the x87 in that most rounding was controlled by the status register, but the 68040 and ColdFire added alternative instructions that specify the rounding mode directly. Thus both the 68040 and ColdFire have the following: "fadd.fmt" (rounding controlled by FPSCR), "fsadd.fmt" (round to single precision) and "fdadd.fmt" (round to double precision). However, gcc handles the rounding differently for the 68040 and ColdFire. The 680x0 patterns use a rounding attribute (<FP:round>) which maps to the following print_operand sequences: %$ : single-precision rounding ("s" for 68040, "" otherwise) %& : double-precision rounding ("d" for 68040, "" otherwise) Thus the patterns can be shared between <68040 and 68040 architectures and still get the rounding right on the 68040. ColdFire instead uses separate patterns for pretty much everything, and uses the <FP:prec> attribute to specify both the precision _and_ the rouding. The bug was that, presumably due to cut-&-paste from the 680x0 patterns, the ColdFire addition and subtraction patterns were using <FP:round> rather than <FP:prec> for the rounding mode. They were therefore using %$ and %&, which both map to empty strings on ColdFire. This patch adds all the missing rounding specifications that I could find. The main question was: should we extend the "%$" and "%&" handling to ColdFire or hard-code the rounding as "s" and "d"? I think we should be consistent -- either do the former everywhere, or do the latter everywhere -- and the latter seemed the less invasive fix. A more ambitious fix would be to combine all the ColdFire and 680x0 SFmode and DFmode patterns, but not today ;) Richard gcc/ * config/m68k/m68k.md (movsf_cf_hard): Use fsmove instead of f%$smove and f%$move. (movdf_cf_hard): Use fdmove for cases 0 and 3 and fmove for case 1. (extendsfdf2_cf): Use fdmove instead of f%&move. (truncdfsf2_cf): Use fsmove instead of f%$smove. (add<mode>3_cf, sub<mode>3_cf): Use <FP:prec> instead of <FP:round>. Index: gcc/config/m68k/m68k.md =================================================================== --- gcc/config/m68k/m68k.md 2007-01-09 15:02:11.000000000 +0000 +++ gcc/config/m68k/m68k.md 2007-01-09 15:02:11.000000000 +0000 @@ -903,12 +903,10 @@ (define_insn "movsf_cf_hard" if (FP_REG_P (operands[0])) { if (ADDRESS_REG_P (operands[1])) - return "move%.l %1,%-;f%$smove%.s %+,%0"; + return "move%.l %1,%-;fsmove%.s %+,%0"; if (FP_REG_P (operands[1])) - return "f%$move%.d %1,%0"; - if (GET_CODE (operands[1]) == CONST_DOUBLE) - return output_move_const_single (operands); - return "f%$move%.s %f1,%0"; + return "fsmove%.d %1,%0"; + return "fsmove%.s %f1,%0"; } if (FP_REG_P (operands[1])) { @@ -1020,11 +1018,13 @@ (define_insn "movdf_cf_hard" switch (which_alternative) { default: + return "fdmove%.d %1,%0"; + case 1: return "fmove%.d %1,%0"; case 2: return "fmove%.d %1,%-;move%.l %+,%0;move%.l %+,%R0"; case 3: - return "move%.l %R1,%-;move%.l %1,%-;f%&move%.d %+,%0"; + return "move%.l %R1,%-;move%.l %1,%-;fdmove%.d %+,%0"; case 4: case 5: case 6: return output_move_double (operands); case 7: @@ -1639,9 +1639,9 @@ (define_insn "extendsfdf2_cf" cc_status = cc_prev_status; return ""; } - return "f%&move%.d %1,%0"; + return "fdmove%.d %1,%0"; } - return "f%&move%.s %f1,%0"; + return "fdmove%.s %f1,%0"; }) ;; This cannot output into an f-reg because there is no way to be @@ -1671,7 +1671,7 @@ (define_insn "truncdfsf2_cf" (match_operand:DF 1 "general_operand" "m,f")))] "TARGET_COLDFIRE_FPU" "@ - f%$move%.d %1,%0 + fsmove%.d %1,%0 fmove%.s %1,%0") (define_insn "" @@ -2366,8 +2366,8 @@ (define_insn "add<mode>3_cf" "TARGET_COLDFIRE_FPU" { if (FP_REG_P (operands[2])) - return "f<FP:round>add%.d %2,%0"; - return "f<FP:round>add%.<FP:prec> %2,%0"; + return "f<FP:prec>add%.d %2,%0"; + return "f<FP:prec>add%.<FP:prec> %2,%0"; }) \f ;; subtract instructions @@ -2575,8 +2575,8 @@ (define_insn "sub<mode>3_cf" "TARGET_COLDFIRE_FPU" { if (FP_REG_P (operands[2])) - return "f<FP:round>sub%.d %2,%0"; - return "f<FP:round>sub%.<FP:prec> %2,%0"; + return "f<FP:prec>sub%.d %2,%0"; + return "f<FP:prec>sub%.<FP:prec> %2,%0"; }) \f ;; multiply instructions ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 31/63] Fix rounding problems in fpgnulib.c 2007-01-10 11:38 ` [ColdFire 30/63] Fix rounding for ColdFire FPUs Richard Sandiford @ 2007-01-10 11:39 ` Richard Sandiford 2007-01-10 11:41 ` [ColdFire 32/63] Delete USE_RETURN_INSN Richard Sandiford 2007-01-11 17:40 ` [ColdFire 31/63] Fix rounding problems in fpgnulib.c Jeffrey Law 2007-01-11 17:35 ` [ColdFire 30/63] Fix rounding for ColdFire FPUs Jeffrey Law 1 sibling, 2 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 11:39 UTC (permalink / raw) To: gcc-patches This patch fixes two bugs in fpgnulib.c's __truncdfsf2. First, it was not rounding to nearest even; it was rounding halfway cases towards infinity instead. Second, it was not detecting overflow in subnormal numbers (i.e. cases where a DFmode subnormal rounds to FLT_MIN). Richard gcc/ 200x-xx-xx Nathan Sidwell <nathan@codesourcery.com> * config/m68k/fpgnulib.c (__truncdfsf2): Implement round to nearest even, fix denormal rounding overflow. Index: gcc/config/m68k/fpgnulib.c =================================================================== --- gcc/config/m68k/fpgnulib.c 2007-01-09 15:02:03.000000000 +0000 +++ gcc/config/m68k/fpgnulib.c 2007-01-09 15:02:11.000000000 +0000 @@ -277,6 +277,8 @@ __truncdfsf2 (double a1) register long mant; register union float_long fl; register union double_long dl1; + int sticky; + int shift; dl1.d = a1; @@ -288,29 +290,45 @@ __truncdfsf2 (double a1) exp = EXPD (dl1) - EXCESSD + EXCESS; + sticky = dl1.l.lower & ((1 << 22) - 1); + mant = MANTD (dl1); /* shift double mantissa 6 bits so we can round */ - mant = MANTD (dl1) >> 6; + sticky |= mant & ((1 << 6) - 1); + mant >>= 6; /* Check for underflow and denormals. */ if (exp <= 0) { if (exp < -24) - mant = 0; + { + sticky |= mant; + mant = 0; + } else - mant >>= 1 - exp; + { + sticky |= mant & ((1 << (1 - exp)) - 1); + mant >>= 1 - exp; + } exp = 0; } - /* now round and shift down */ - mant += 1; - mant >>= 1; - - /* did the round overflow? */ - if (mant & 0xFF000000L) + /* now round */ + shift = 1; + if ((mant & 1) && (sticky || (mant & 2))) { - mant >>= 1; - exp++; + int rounding = exp ? 2 : 1; + + mant += 1; + + /* did the round overflow? */ + if (mant >= (HIDDEN << rounding)) + { + exp++; + shift = rounding; + } } + /* shift down */ + mant >>= shift; mant &= ~HIDDEN; ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 32/63] Delete USE_RETURN_INSN 2007-01-10 11:39 ` [ColdFire 31/63] Fix rounding problems in fpgnulib.c Richard Sandiford @ 2007-01-10 11:41 ` Richard Sandiford 2007-01-10 11:42 ` [ColdFire 33/63] Force an epilogue when restoring FPU registers Richard Sandiford 2007-01-10 17:57 ` [ColdFire 32/63] Delete USE_RETURN_INSN Jeffrey Law 2007-01-11 17:40 ` [ColdFire 31/63] Fix rounding problems in fpgnulib.c Jeffrey Law 1 sibling, 2 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 11:41 UTC (permalink / raw) To: gcc-patches This patch gets rid of: XXX This macro is m68k-specific and only used in m68k.md. */ #define USE_RETURN_INSN use_return_insn () It seems a bit daft to wrap this one function in a macro, especially if it creates enough confusion for a "XXX" comment to be needed. Richard gcc/ 200x-xx-xx Kazu Hirata <kazu@codesourcery.com> * config/m68k/m68k-protos.h (use_return_insn): Rename to... (m68k_use_return_insn): ...this. * config/m68k/m68k.h (USE_RETURN_INSN): Delete. * config/m68k/m68k.c (use_return_insn): Rename to... (m68k_use_return_insn): ...this. * config/m68k/m68k.md (return): Use m68k_use_return_insn instead of USE_RETURN_INSN. Index: gcc/config/m68k/m68k-protos.h =================================================================== --- gcc/config/m68k/m68k-protos.h 2007-01-09 15:02:09.000000000 +0000 +++ gcc/config/m68k/m68k-protos.h 2007-01-09 15:02:12.000000000 +0000 @@ -65,7 +65,7 @@ extern int emit_move_sequence (rtx *, en extern bool m68k_regno_mode_ok (int, enum machine_mode); extern int flags_in_68881 (void); -extern bool use_return_insn (void); +extern bool m68k_use_return_insn (void); extern void override_options (void); extern const char *m68k_cpp_cpu_ident (const char *); extern const char *m68k_cpp_cpu_family (const char *); Index: gcc/config/m68k/m68k.h =================================================================== --- gcc/config/m68k/m68k.h 2007-01-09 15:02:09.000000000 +0000 +++ gcc/config/m68k/m68k.h 2007-01-09 15:02:12.000000000 +0000 @@ -645,12 +645,6 @@ #define FUNCTION_PROFILER(FILE, LABELNO) #define EXIT_IGNORE_STACK 1 -/* Determine if the epilogue should be output as RTL. - You should override this if you define FUNCTION_EXTRA_EPILOGUE. - - XXX This macro is m68k-specific and only used in m68k.md. */ -#define USE_RETURN_INSN use_return_insn () - /* Output assembler code for a block containing the constant parts of a trampoline, leaving space for the variable parts. Index: gcc/config/m68k/m68k.c =================================================================== --- gcc/config/m68k/m68k.c 2007-01-09 15:02:10.000000000 +0000 +++ gcc/config/m68k/m68k.c 2007-01-09 15:02:12.000000000 +0000 @@ -1046,7 +1046,7 @@ m68k_output_function_prologue (FILE *str /* Return true if this function's epilogue can be output as RTL. */ bool -use_return_insn (void) +m68k_use_return_insn (void) { if (!reload_completed || frame_pointer_needed || get_frame_size () != 0) return false; Index: gcc/config/m68k/m68k.md =================================================================== --- gcc/config/m68k/m68k.md 2007-01-09 15:02:11.000000000 +0000 +++ gcc/config/m68k/m68k.md 2007-01-09 15:02:12.000000000 +0000 @@ -6467,7 +6467,7 @@ (define_insn "nop" ;; Used for frameless functions which save no regs and allocate no locals. (define_insn "return" [(return)] - "USE_RETURN_INSN" + "m68k_use_return_insn ()" { if (current_function_pops_args == 0) return "rts"; ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 33/63] Force an epilogue when restoring FPU registers 2007-01-10 11:41 ` [ColdFire 32/63] Delete USE_RETURN_INSN Richard Sandiford @ 2007-01-10 11:42 ` Richard Sandiford 2007-01-10 11:44 ` [ColdFire 34/63] Don't emit a nop after noreturn calls Richard Sandiford 2007-01-10 17:57 ` [ColdFire 33/63] Force an epilogue when restoring FPU registers Jeffrey Law 2007-01-10 17:57 ` [ColdFire 32/63] Delete USE_RETURN_INSN Jeffrey Law 1 sibling, 2 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 11:42 UTC (permalink / raw) To: gcc-patches m68k_use_return_insn correctly returns false if the function needs to restore integer registers; in that case we need a normal epilogue. Hoewver, it was failing to do the same if the function needs to restore floating-point registers. Richard gcc/ * config/m68k/m68k.c (m68k_use_return_insn): Update comments before function. Extend register save check to include all registers, not just integer ones. Index: gcc/config/m68k/m68k.c =================================================================== --- gcc/config/m68k/m68k.c 2007-01-09 15:02:12.000000000 +0000 +++ gcc/config/m68k/m68k.c 2007-01-09 15:02:13.000000000 +0000 @@ -1043,7 +1043,8 @@ m68k_output_function_prologue (FILE *str } } \f -/* Return true if this function's epilogue can be output as RTL. */ +/* Return true if a simple (return) instruction is sufficient for this + instruction (i.e. if no epilogue is needed). */ bool m68k_use_return_insn (void) @@ -1051,10 +1052,8 @@ m68k_use_return_insn (void) if (!reload_completed || frame_pointer_needed || get_frame_size () != 0) return false; - /* We can output the epilogue as RTL only if no registers need to be - restored. */ m68k_compute_frame_layout (); - return current_frame.reg_no ? false : true; + return current_frame.offset == 0; } /* This function generates the assembly code for function exit, ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 34/63] Don't emit a nop after noreturn calls 2007-01-10 11:42 ` [ColdFire 33/63] Force an epilogue when restoring FPU registers Richard Sandiford @ 2007-01-10 11:44 ` Richard Sandiford 2007-01-10 11:46 ` [RTL, ColdFire 35/63] Expose dual %d0/%a0 return value in RTL Richard Sandiford 2007-01-10 17:58 ` [ColdFire 34/63] Don't emit a nop after noreturn calls Jeffrey Law 2007-01-10 17:57 ` [ColdFire 33/63] Force an epilogue when restoring FPU registers Jeffrey Law 1 sibling, 2 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 11:44 UTC (permalink / raw) To: gcc-patches m68k_output_function_epilogue has code to output a NOP after a noreturn call. It's there so that gdb can tell that the call came from the current function, not the one after it. However, Dan says that gdb doesn't need such help now, so this patch removes it. Richard gcc/ 200x-xx-xx Kazu Hirata <kazu@codesourcery.com> * config/m68k/m68k.c (m68k_output_function_epilogue): Don't output a NOP for empty epilogues. Index: gcc/config/m68k/m68k.c =================================================================== --- gcc/config/m68k/m68k.c 2007-01-09 15:02:13.000000000 +0000 +++ gcc/config/m68k/m68k.c 2007-01-09 15:02:13.000000000 +0000 @@ -1079,12 +1079,7 @@ m68k_output_function_epilogue (FILE *str if (GET_CODE (insn) == NOTE) insn = prev_nonnote_insn (insn); if (insn && GET_CODE (insn) == BARRIER) - { - /* Output just a no-op so that debuggers don't get confused - about which function the pc is in at this address. */ - fprintf (stream, "\tnop\n"); - return; - } + return; #ifdef FUNCTION_EXTRA_EPILOGUE FUNCTION_EXTRA_EPILOGUE (stream, size); ^ permalink raw reply [flat|nested] 280+ messages in thread
* [RTL, ColdFire 35/63] Expose dual %d0/%a0 return value in RTL 2007-01-10 11:44 ` [ColdFire 34/63] Don't emit a nop after noreturn calls Richard Sandiford @ 2007-01-10 11:46 ` Richard Sandiford 2007-01-10 11:49 ` [ColdFire 36/63] Use RTL for prologues and epilogues Richard Sandiford 2007-01-12 16:09 ` [RTL, ColdFire 35/63] Expose dual %d0/%a0 return value in RTL Ian Lance Taylor 2007-01-10 17:58 ` [ColdFire 34/63] Don't emit a nop after noreturn calls Jeffrey Law 1 sibling, 2 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 11:46 UTC (permalink / raw) To: gcc-patches GNU/Linux and NetBSD return pointers in %a0. However, to support code that doesn't prototype functions properly, they also return a copy in %d0. The code that does this is a bit ad-hoc. During the epilogue, it scans back to see if %d0 is already provably the same as %a0, and adds a move if not. It seems better to expose the move at the rtl level instead. This patch does that by extending the definition of TARGET_FUNCTION_VALUE so that the first element of a PARALLEL can span the entire return value and so that later elements contain complete or partial copies of it. Callers should treat the first element as the canonical one. The caller side already handles such PARALLELs correctly; it's just like the normal PARALLEL case except that the parts happen to overlap. Only the caller side needs adjusting. Richard gcc/ 200x-xx-xx Kazu Hirata <kazu@codesourcery.com> Richard Sandiford <richard@codesourcery.com> * doc/tm.texi (TARGET_FUNCTION_VALUE): Expand documentation of parallels. * calls.c (expand_call): If the return value is a PARALLEL, extract its first member. * config/m68k/linux.h (FUNCTION_EXTRA_EPILOGUE): Remove. * config/m68k/m68k.c (m68k_output_function_epilogue): Don't use FUNCTION_EXTRA_EPILOGUE. (m68k_function_value): Return a PARALLEL if the return value is of a pointer type. * config/m68k/netbsd-elf.h (current_function_returns_pointer) (FUNCTION_EXTRA_EPILOGUE): Remove. * config/m68k/m68k.md (D0_REG): New constant. Index: gcc/doc/tm.texi =================================================================== --- gcc/doc/tm.texi 2007-01-09 15:02:06.000000000 +0000 +++ gcc/doc/tm.texi 2007-01-09 15:02:13.000000000 +0000 @@ -4103,7 +4103,12 @@ place regardless of mode.) The value of @code{reg} RTX for the hard register where the return value is stored. The value can also be a @code{parallel} RTX, if the return value is in multiple places. See @code{FUNCTION_ARG} for an explanation of the -@code{parallel} form. +@code{parallel} form. Note that the callee will populate every +location specified in the @code{parallel}, but if the first element of +the @code{parallel} contains the whole return value, callers will use +that element as the canonical location and ignore the others. The m68k +port uses this type of @code{parallel} to return pointers in both +@samp{%a0} (the canonical location) and @samp{%d0}. If @code{TARGET_PROMOTE_FUNCTION_RETURN} returns true, you must apply the same promotion rules specified in @code{PROMOTE_MODE} if Index: gcc/calls.c =================================================================== --- gcc/calls.c 2007-01-09 13:18:12.000000000 +0000 +++ gcc/calls.c 2007-01-09 15:02:13.000000000 +0000 @@ -2536,6 +2536,19 @@ expand_call (tree exp, rtx target, int i else valreg = hard_function_value (TREE_TYPE (exp), fndecl, fntype, (pass == 0)); + + /* If VALREG is a PARALLEL whose first member has a zero + offset, use that. This is for targets such as m68k that + return the same value in multiple places. */ + if (GET_CODE (valreg) == PARALLEL) + { + rtx elem = XVECEXP (valreg, 0, 0); + rtx where = XEXP (elem, 0); + rtx offset = XEXP (elem, 1); + if (offset == const0_rtx + && GET_MODE (where) == GET_MODE (valreg)) + valreg = where; + } } /* Precompute all register parameters. It isn't safe to compute anything Index: gcc/config/m68k/linux.h =================================================================== --- gcc/config/m68k/linux.h 2007-01-09 15:02:05.000000000 +0000 +++ gcc/config/m68k/linux.h 2007-01-09 15:02:13.000000000 +0000 @@ -179,20 +179,6 @@ #define NEEDS_UNTYPED_CALL 1 #define FUNCTION_VALUE(VALTYPE, FUNC) \ m68k_function_value (VALTYPE, FUNC) -/* For compatibility with the large body of existing code which does - not always properly declare external functions returning pointer - types, the m68k/SVR4 convention is to copy the value returned for - pointer functions from a0 to d0 in the function epilogue, so that - callers that have neglected to properly declare the callee can - still find the correct return value. */ - -#define FUNCTION_EXTRA_EPILOGUE(FILE, SIZE) \ -do { \ - if (current_function_returns_pointer \ - && ! find_equiv_reg (0, get_last_insn (), 0, 0, 0, 8, Pmode)) \ - asm_fprintf (FILE, "\tmove.l %Ra0,%Rd0\n"); \ -} while (0); - /* Define how to find the value returned by a library function assuming the value has mode MODE. For m68k/SVR4 look for integer values in d0, pointer values in d0 Index: gcc/config/m68k/m68k.c =================================================================== --- gcc/config/m68k/m68k.c 2007-01-09 15:02:13.000000000 +0000 +++ gcc/config/m68k/m68k.c 2007-01-09 15:02:13.000000000 +0000 @@ -1081,10 +1081,6 @@ m68k_output_function_epilogue (FILE *str if (insn && GET_CODE (insn) == BARRIER) return; -#ifdef FUNCTION_EXTRA_EPILOGUE - FUNCTION_EXTRA_EPILOGUE (stream, size); -#endif - fsize = current_frame.size; /* FIXME: leaf_function_p below is too strong. @@ -4130,9 +4126,26 @@ m68k_function_value (tree valtype, tree break; } - /* If the function returns a pointer, push that into %a0 */ - if (POINTER_TYPE_P (valtype)) - return gen_rtx_REG (mode, 8); + /* If the function returns a pointer, push that into %a0. */ + if (func && POINTER_TYPE_P (TREE_TYPE (TREE_TYPE (func)))) + /* For compatibility with the large body of existing code which + does not always properly declare external functions returning + pointer types, the m68k/SVR4 convention is to copy the value + returned for pointer functions from a0 to d0 in the function + epilogue, so that callers that have neglected to properly + declare the callee can still find the correct return value in + d0. */ + return gen_rtx_PARALLEL + (mode, + gen_rtvec (2, + gen_rtx_EXPR_LIST (VOIDmode, + gen_rtx_REG (mode, A0_REG), + const0_rtx), + gen_rtx_EXPR_LIST (VOIDmode, + gen_rtx_REG (mode, D0_REG), + const0_rtx))); + else if (POINTER_TYPE_P (valtype)) + return gen_rtx_REG (mode, A0_REG); else - return gen_rtx_REG (mode, 0); + return gen_rtx_REG (mode, D0_REG); } Index: gcc/config/m68k/netbsd-elf.h =================================================================== --- gcc/config/m68k/netbsd-elf.h 2007-01-09 15:02:00.000000000 +0000 +++ gcc/config/m68k/netbsd-elf.h 2007-01-09 15:02:13.000000000 +0000 @@ -273,24 +273,6 @@ #define FUNCTION_VALUE(VALTYPE, FUNC) m68k_function_value (VALTYPE, FUNC) -/* For compatibility with the large body of existing code which does - not always properly declare external functions returning pointer - types, the m68k/SVR4 convention is to copy the value returned for - pointer functions from a0 to d0 in the function epilogue, so that - callers that have neglected to properly declare the callee can - still find the correct return value. */ - -extern int current_function_returns_pointer; -#define FUNCTION_EXTRA_EPILOGUE(FILE, SIZE) \ -do \ - { \ - if (current_function_returns_pointer \ - && ! find_equiv_reg (0, get_last_insn (), 0, 0, 0, 8, Pmode)) \ - asm_fprintf (FILE, "\tmove.l %Ra0,%Rd0\n"); \ - } \ -while (0) - - /* Define how to find the value returned by a library function assuming the value has mode MODE. For m68k/SVR4 look for integer values in d0, pointer values in d0 Index: gcc/config/m68k/m68k.md =================================================================== --- gcc/config/m68k/m68k.md 2007-01-09 15:02:12.000000000 +0000 +++ gcc/config/m68k/m68k.md 2007-01-09 15:02:13.000000000 +0000 @@ -124,7 +124,8 @@ (define_constants ;; Registers by name. (define_constants - [(A0_REG 8) + [(D0_REG 0) + (A0_REG 8) (SP_REG 15) ]) ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 36/63] Use RTL for prologues and epilogues 2007-01-10 11:46 ` [RTL, ColdFire 35/63] Expose dual %d0/%a0 return value in RTL Richard Sandiford @ 2007-01-10 11:49 ` Richard Sandiford 2007-01-10 11:50 ` [ColdFire 37/63] " Richard Sandiford ` (3 more replies) 2007-01-12 16:09 ` [RTL, ColdFire 35/63] Expose dual %d0/%a0 return value in RTL Ian Lance Taylor 1 sibling, 4 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 11:49 UTC (permalink / raw) To: gcc-patches This patch converts the prologue and epilogue code to use "prologue" and "epilogue" rtl expanders. It improves the debuggability of prologues and epilogues and paves the way for scheduling them in future (if any m68k schedulers are added). The patch tries to preserve the existing code-generation decisions where possible. However, gcc.c-torture/execute/921113-1.c showed up a bug in the old handling of big stack frames on ColdFire. If the frame is so big that the saved registers cannot be reached from %fp using 16-bit offsets, the 680x0 epilogue code will load the frame size into %a1 and use accesses of the form (d8,%fp,%a1). ColdFire can do the same when restoring registers individually, but unfortunately, the ColdFire movems don't support (d8,%fp,%a1). We therefore have to add %fp to %a1 and use the new %a1 as a base address in the movems. This new %a1 is used for both general register restores (movem) and floating-point restores (fmovem). The problem is that the add is part of the movem code, and that code is only needed when restoring 3 or more general registers. In other cases, floating-point restores will be from the unmodified %a1 (i.e. "-framesize"). Also, we have: /* Because the ColdFire doesn't support moveml with complex address modes we make an extra correction here. */ if (m68k_arch_coldfire) fsize += current_frame.offset; But this is wrong when restoring registers individually. The code to restore individual registers assumes that %a1 contains -fsize, not -(fsize + current_frame.offset). Making the current scheme work would mean adding yet more rarely-used special cases. I don't think that's a good solution. Given the addressing-mode restrictions, I think the best fix is to simply use a stack-based restore for big ColdFire frames if we need to use movem or fmovem. In other words, we set %sp from %fp in that case. The new lea is two bytes longer than the old add, so this makes the epilogue 2 bytes longer for the case that previously worked (i.e. 3 or more general registers restored, no FP registers stored). The upside is that we can now use plain (%sp)+ addresses when restoring 1 or 2 general registers. We can also use (%sp) for fmovem when restoring 0, 1 or 2 general registers. Richard gcc/ 200x-xx-xx Kazu Hirata <kazu@codesourcery.com> Richard Sandiford <richard@codesourcery.com> * config/m68k/m68k-protos.h (m68k_interrupt_function_p): Declare. (m68k_movem_pattern_p, m68k_output_movem): Likewise. (m68k_expand_prologue, m68k_expand_epilogue): Likewise. * config/m68k/m68k.h (EPILOGUE_USES): Define. Treat all registers as being live on exit from an interrupt function. (PRINT_OPERAND_PUNCT_VALID_P): Return true for '?'. * config/m68k/m68k.c (MIN_MOVEM_REGS, MIN_FMOVEM_REGS): New macros. (m68k_frame): Remove reg_rev_mask and fpu_rev_mask. (TARGET_ASM_FUNCTION_PROLOGUE, TARGET_ASM_FUNCTION_EPILOGUE): Delete. (m68k_interrupt_function_p): Globalize. (m68k_compute_frame_layout): Remove reverse mask code. (m68k_emit_movem, m68k_set_frame_related): New functions. (m68k_output_function_prologue): Delete in favor of... (m68k_expand_prologue): ...this new function. (m68k_output_function_epilogue): Delete in favor of... (m68k_expand_epilogue): ...this new function. (m68k_split_offset, m68k_movem_pattern_p, m68k_output_movem): New functions. (print_operand): Handle %?. * config/m68k/m68k.md (UNSPEC_SIN, UNSPEC_COS): Remove excess space. (UNSPEC_GOT, A1_REG, PIC_REG, FP0_REG): New constants. (prologue, epilogue): New patterns. (return): Turn into a define_expand. (*return): New pattern, derived from old "return" pattern. Use rte rather than rts for interrupt functions. Only use rtd if the pop count is nonzero. (*m68k_store_multiple, *m68k_store_multiple_automod): New patterns. (*m68k_load_multiple, *m68k_load_multiple_automod): Likewise. (link, *link, unlink, *unlink, load_got): Likewise. Index: gcc/config/m68k/m68k-protos.h =================================================================== *** gcc/config/m68k/m68k-protos.h 2007-01-09 15:02:12.000000000 +0000 --- gcc/config/m68k/m68k-protos.h 2007-01-09 15:02:15.000000000 +0000 *************** the Free Software Foundation; either ver *** 21,26 **** --- 21,27 ---- /* Define functions defined in aux-output.c and used in templates. */ #ifdef RTX_CODE + extern bool m68k_interrupt_function_p (tree); extern HOST_WIDE_INT m68k_initial_elimination_offset (int from, int to); extern const char *output_move_const_into_data_reg (rtx *); extern int valid_mov3q_const (rtx); *************** extern int valid_dbcc_comparison_p_2 (rt *** 60,71 **** --- 61,76 ---- extern rtx m68k_libcall_value (enum machine_mode); extern rtx m68k_function_value (tree, tree); extern int emit_move_sequence (rtx *, enum machine_mode, rtx); + extern bool m68k_movem_pattern_p (rtx, rtx, HOST_WIDE_INT, bool); + extern const char *m68k_output_movem (rtx *, rtx, HOST_WIDE_INT, bool); #endif /* RTX_CODE */ extern bool m68k_regno_mode_ok (int, enum machine_mode); extern int flags_in_68881 (void); + extern void m68k_expand_prologue (void); extern bool m68k_use_return_insn (void); + extern void m68k_expand_epilogue (void); extern void override_options (void); extern const char *m68k_cpp_cpu_ident (const char *); extern const char *m68k_cpp_cpu_family (const char *); Index: gcc/config/m68k/m68k.h =================================================================== *** gcc/config/m68k/m68k.h 2007-01-09 15:02:12.000000000 +0000 --- gcc/config/m68k/m68k.h 2007-01-09 15:02:15.000000000 +0000 *************** #define DWARF_FRAME_REGNUM(REG) REG *** 976,981 **** --- 976,985 ---- /* Before the prologue, the top of the frame is at 4(%sp). */ #define INCOMING_FRAME_SP_OFFSET 4 + /* All registers are live on exit from an interrupt routine. */ + #define EPILOGUE_USES(REGNO) \ + (reload_completed && m68k_interrupt_function_p (current_function_decl)) + /* Describe how we implement __builtin_eh_return. */ #define EH_RETURN_DATA_REGNO(N) \ ((N) < 2 ? (N) : INVALID_REGNUM) *************** #define ASM_OUTPUT_LONG_DOUBLE_OPERAND(F *** 1112,1117 **** --- 1116,1122 ---- '$' for the letter `s' in an op code, but only on the 68040. '&' for the letter `d' in an op code, but only on the 68040. '/' for register prefix needed by longlong.h. + '?' for m68k_library_id_string 'b' for byte insn (no effect, on the Sun; this is for the ISI). 'd' to force memory addressing to be absolute, not relative. *************** #define ASM_OUTPUT_LONG_DOUBLE_OPERAND(F *** 1122,1128 **** #define PRINT_OPERAND_PUNCT_VALID_P(CODE) \ ((CODE) == '.' || (CODE) == '#' || (CODE) == '-' \ || (CODE) == '+' || (CODE) == '@' || (CODE) == '!' \ ! || (CODE) == '$' || (CODE) == '&' || (CODE) == '/') /* See m68k.c for the m68k specific codes. */ --- 1127,1133 ---- #define PRINT_OPERAND_PUNCT_VALID_P(CODE) \ ((CODE) == '.' || (CODE) == '#' || (CODE) == '-' \ || (CODE) == '+' || (CODE) == '@' || (CODE) == '!' \ ! || (CODE) == '$' || (CODE) == '&' || (CODE) == '/' || (CODE) == '?') /* See m68k.c for the m68k specific codes. */ Index: gcc/config/m68k/m68k.c =================================================================== *** gcc/config/m68k/m68k.c 2007-01-09 15:02:13.000000000 +0000 --- gcc/config/m68k/m68k.c 2007-01-09 15:02:15.000000000 +0000 *************** enum reg_class regno_reg_class[] = *** 70,75 **** --- 70,85 ---- #endif + /* The minimum number of integer registers that we want to save with the + movem instruction. Using two movel instructions instead of a single + moveml is about 15% faster for the 68020 and 68030 at no expense in + code size. */ + #define MIN_MOVEM_REGS 3 + + /* The minimum number of floating point registers that we want to save + with the fmovem instruction. */ + #define MIN_FMOVEM_REGS 1 + /* Structure describing stack frame layout. */ struct m68k_frame { *************** struct m68k_frame *** 85,96 **** /* Data and address register. */ int reg_no; unsigned int reg_mask; - unsigned int reg_rev_mask; /* FPU registers. */ int fpu_no; unsigned int fpu_mask; - unsigned int fpu_rev_mask; /* Offsets relative to ARG_POINTER. */ HOST_WIDE_INT frame_pointer_offset; --- 95,104 ---- *************** struct m68k_address { *** 127,141 **** static bool m68k_handle_option (size_t, const char *, int); static rtx find_addr_reg (rtx); static const char *singlemove_string (rtx *); - static void m68k_output_function_prologue (FILE *, HOST_WIDE_INT); - static void m68k_output_function_epilogue (FILE *, HOST_WIDE_INT); #ifdef M68K_TARGET_COFF static void m68k_coff_asm_named_section (const char *, unsigned int, tree); #endif /* M68K_TARGET_COFF */ static void m68k_output_mi_thunk (FILE *, tree, HOST_WIDE_INT, HOST_WIDE_INT, tree); static rtx m68k_struct_value_rtx (tree, int); - static bool m68k_interrupt_function_p (tree func); static tree m68k_handle_fndecl_attribute (tree *node, tree name, tree args, int flags, bool *no_add_attrs); --- 135,146 ---- *************** #define TARGET_ASM_UNALIGNED_HI_OP TARGE *** 183,193 **** #undef TARGET_ASM_UNALIGNED_SI_OP #define TARGET_ASM_UNALIGNED_SI_OP TARGET_ASM_ALIGNED_SI_OP - #undef TARGET_ASM_FUNCTION_PROLOGUE - #define TARGET_ASM_FUNCTION_PROLOGUE m68k_output_function_prologue - #undef TARGET_ASM_FUNCTION_EPILOGUE - #define TARGET_ASM_FUNCTION_EPILOGUE m68k_output_function_epilogue - #undef TARGET_ASM_OUTPUT_MI_THUNK #define TARGET_ASM_OUTPUT_MI_THUNK m68k_output_mi_thunk #undef TARGET_ASM_CAN_OUTPUT_MI_THUNK --- 188,193 ---- *************** m68k_cpp_cpu_family (const char *prefix) *** 632,639 **** \f /* Return nonzero if FUNC is an interrupt function as specified by the "interrupt_handler" attribute. */ ! static bool ! m68k_interrupt_function_p(tree func) { tree a; --- 632,639 ---- \f /* Return nonzero if FUNC is an interrupt function as specified by the "interrupt_handler" attribute. */ ! bool ! m68k_interrupt_function_p (tree func) { tree a; *************** m68k_handle_fndecl_attribute (tree *node *** 666,672 **** m68k_compute_frame_layout (void) { int regno, saved; ! unsigned int mask, rmask; bool interrupt_handler = m68k_interrupt_function_p (current_function_decl); /* Only compute the frame once per function. --- 666,672 ---- m68k_compute_frame_layout (void) { int regno, saved; ! unsigned int mask; bool interrupt_handler = m68k_interrupt_function_p (current_function_decl); /* Only compute the frame once per function. *************** m68k_compute_frame_layout (void) *** 677,704 **** current_frame.size = (get_frame_size () + 3) & -4; ! mask = rmask = saved = 0; for (regno = 0; regno < 16; regno++) if (m68k_save_reg (regno, interrupt_handler)) { ! mask |= 1 << regno; ! rmask |= 1 << (15 - regno); saved++; } current_frame.offset = saved * 4; current_frame.reg_no = saved; current_frame.reg_mask = mask; - current_frame.reg_rev_mask = rmask; current_frame.foffset = 0; ! mask = rmask = saved = 0; if (TARGET_HARD_FLOAT) { for (regno = 16; regno < 24; regno++) if (m68k_save_reg (regno, interrupt_handler)) { ! mask |= 1 << (regno - 16); ! rmask |= 1 << (23 - regno); saved++; } current_frame.foffset = saved * TARGET_FP_REG_SIZE; --- 677,701 ---- current_frame.size = (get_frame_size () + 3) & -4; ! mask = saved = 0; for (regno = 0; regno < 16; regno++) if (m68k_save_reg (regno, interrupt_handler)) { ! mask |= 1 << (regno - D0_REG); saved++; } current_frame.offset = saved * 4; current_frame.reg_no = saved; current_frame.reg_mask = mask; current_frame.foffset = 0; ! mask = saved = 0; if (TARGET_HARD_FLOAT) { for (regno = 16; regno < 24; regno++) if (m68k_save_reg (regno, interrupt_handler)) { ! mask |= 1 << (regno - FP0_REG); saved++; } current_frame.foffset = saved * TARGET_FP_REG_SIZE; *************** m68k_compute_frame_layout (void) *** 706,712 **** } current_frame.fpu_no = saved; current_frame.fpu_mask = mask; - current_frame.fpu_rev_mask = rmask; /* Remember what function this frame refers to. */ current_frame.funcdef_no = current_function_funcdef_no; --- 703,708 ---- *************** m68k_save_reg (unsigned int regno, bool *** 794,947 **** return !call_used_regs[regno]; } ! /* This function generates the assembly code for function entry. ! STREAM is a stdio stream to output the code to. ! SIZE is an int: how many units of temporary storage to allocate. */ static void ! m68k_output_function_prologue (FILE *stream, ! HOST_WIDE_INT size ATTRIBUTE_UNUSED) { HOST_WIDE_INT fsize_with_regs; ! HOST_WIDE_INT cfa_offset = INCOMING_FRAME_SP_OFFSET; ! m68k_compute_frame_layout(); /* If the stack limit is a symbol, we can check it here, before actually allocating the space. */ if (current_function_limit_stack && GET_CODE (stack_limit_rtx) == SYMBOL_REF) ! asm_fprintf (stream, "\tcmp" ASM_DOT "l %I%s+%wd,%Rsp\n\ttrapcs\n", ! XSTR (stack_limit_rtx, 0), current_frame.size + 4); - /* On ColdFire add register save into initial stack frame setup, if possible. */ fsize_with_regs = current_frame.size; if (TARGET_COLDFIRE) { ! if (current_frame.reg_no > 2) ! fsize_with_regs += current_frame.reg_no * 4; ! if (current_frame.fpu_no) ! fsize_with_regs += current_frame.fpu_no * 8; } if (frame_pointer_needed) { ! if (current_frame.size == 0 && TUNE_68040) ! /* on the 68040, pea + move is faster than link.w 0 */ ! fprintf (stream, (MOTOROLA ! ? "\tpea (%s)\n\tmove.l %s,%s\n" ! : "\tpea %s@\n\tmovel %s,%s\n"), ! M68K_REGNAME (FRAME_POINTER_REGNUM), ! M68K_REGNAME (STACK_POINTER_REGNUM), ! M68K_REGNAME (FRAME_POINTER_REGNUM)); ! else if (fsize_with_regs < 0x8000) ! asm_fprintf (stream, "\tlink" ASM_DOTW " %s,%I%wd\n", ! M68K_REGNAME (FRAME_POINTER_REGNUM), -fsize_with_regs); ! else if (TARGET_68020) ! asm_fprintf (stream, "\tlink" ASM_DOTL " %s,%I%wd\n", ! M68K_REGNAME (FRAME_POINTER_REGNUM), -fsize_with_regs); ! else ! /* Adding negative number is faster on the 68040. */ ! asm_fprintf (stream, ! "\tlink" ASM_DOTW " %s,%I0\n" ! "\tadd" ASM_DOT "l %I%wd,%Rsp\n", ! M68K_REGNAME (FRAME_POINTER_REGNUM), -fsize_with_regs); ! } ! else if (fsize_with_regs) /* !frame_pointer_needed */ ! { ! if (fsize_with_regs < 0x8000) { ! if (fsize_with_regs <= 8) ! { ! if (!TARGET_COLDFIRE) ! asm_fprintf (stream, "\tsubq" ASM_DOT "w %I%wd,%Rsp\n", ! fsize_with_regs); ! else ! asm_fprintf (stream, "\tsubq" ASM_DOT "l %I%wd,%Rsp\n", ! fsize_with_regs); ! } ! else if (fsize_with_regs <= 16 && TUNE_CPU32) ! /* On the CPU32 it is faster to use two subqw instructions to ! subtract a small integer (8 < N <= 16) to a register. */ ! asm_fprintf (stream, ! "\tsubq" ASM_DOT "w %I8,%Rsp\n" ! "\tsubq" ASM_DOT "w %I%wd,%Rsp\n", ! fsize_with_regs - 8); ! else if (TUNE_68040) ! /* Adding negative number is faster on the 68040. */ ! asm_fprintf (stream, "\tadd" ASM_DOT "w %I%wd,%Rsp\n", ! -fsize_with_regs); ! else ! asm_fprintf (stream, (MOTOROLA ! ? "\tlea (%wd,%Rsp),%Rsp\n" ! : "\tlea %Rsp@(%wd),%Rsp\n"), ! -fsize_with_regs); ! } ! else /* fsize_with_regs >= 0x8000 */ ! asm_fprintf (stream, "\tadd" ASM_DOT "l %I%wd,%Rsp\n", ! -fsize_with_regs); ! } /* !frame_pointer_needed */ ! ! if (dwarf2out_do_frame ()) ! { ! if (frame_pointer_needed) ! { ! char *l; ! l = (char *) dwarf2out_cfi_label (); ! cfa_offset += 4; ! dwarf2out_reg_save (l, FRAME_POINTER_REGNUM, -cfa_offset); ! dwarf2out_def_cfa (l, FRAME_POINTER_REGNUM, cfa_offset); ! cfa_offset += current_frame.size; ! } else ! { ! cfa_offset += current_frame.size; ! dwarf2out_def_cfa ("", STACK_POINTER_REGNUM, cfa_offset); ! } } if (current_frame.fpu_mask) { if (TARGET_68881) ! { ! asm_fprintf (stream, (MOTOROLA ! ? "\tfmovm %I0x%x,-(%Rsp)\n" ! : "\tfmovem %I0x%x,%Rsp@-\n"), ! current_frame.fpu_mask); ! } else { int offset; ! /* stack already has registers in it. Find the offset from ! the bottom of stack to where the FP registers go */ ! if (current_frame.reg_no <= 2) offset = 0; else ! offset = current_frame.reg_no * 4; ! if (offset) ! asm_fprintf (stream, ! "\tfmovem %I0x%x,%d(%Rsp)\n", ! current_frame.fpu_rev_mask, ! offset); ! else ! asm_fprintf (stream, ! "\tfmovem %I0x%x,(%Rsp)\n", ! current_frame.fpu_rev_mask); ! } ! ! if (dwarf2out_do_frame ()) ! { ! char *l = (char *) dwarf2out_cfi_label (); ! int n_regs, regno; ! ! cfa_offset += current_frame.fpu_no * TARGET_FP_REG_SIZE; ! if (! frame_pointer_needed) ! dwarf2out_def_cfa (l, STACK_POINTER_REGNUM, cfa_offset); ! for (regno = 16, n_regs = 0; regno < 24; regno++) ! if (current_frame.fpu_mask & (1 << (regno - 16))) ! dwarf2out_reg_save (l, regno, -cfa_offset ! + n_regs++ * TARGET_FP_REG_SIZE); } } --- 790,947 ---- return !call_used_regs[regno]; } ! /* Emit RTL for a MOVEM or FMOVEM instruction. BASE + OFFSET represents ! the lowest memory address. COUNT is the number of registers to be ! moved, with register REGNO + I being moved if bit I of MASK is set. ! STORE_P specifies the direction of the move and ADJUST_STACK_P says ! whether or not this is pre-decrement (if STORE_P) or post-increment ! (if !STORE_P) operation. */ ! ! static rtx ! m68k_emit_movem (rtx base, HOST_WIDE_INT offset, ! unsigned int count, unsigned int regno, ! unsigned int mask, bool store_p, bool adjust_stack_p) ! { ! int i; ! rtx body, addr, src, operands[2]; ! enum machine_mode mode; ! ! body = gen_rtx_PARALLEL (VOIDmode, rtvec_alloc (adjust_stack_p + count)); ! mode = reg_raw_mode[regno]; ! i = 0; ! ! if (adjust_stack_p) ! { ! src = plus_constant (base, (count ! * GET_MODE_SIZE (mode) ! * (HOST_WIDE_INT) (store_p ? -1 : 1))); ! XVECEXP (body, 0, i++) = gen_rtx_SET (VOIDmode, base, src); ! } ! ! for (; mask != 0; mask >>= 1, regno++) ! if (mask & 1) ! { ! addr = plus_constant (base, offset); ! operands[!store_p] = gen_frame_mem (mode, addr); ! operands[store_p] = gen_rtx_REG (mode, regno); ! XVECEXP (body, 0, i++) ! = gen_rtx_SET (VOIDmode, operands[0], operands[1]); ! offset += GET_MODE_SIZE (mode); ! } ! gcc_assert (i == XVECLEN (body, 0)); ! ! return emit_insn (body); ! } ! ! /* Make INSN a frame-related instruction. */ static void ! m68k_set_frame_related (rtx insn) ! { ! rtx body; ! int i; ! ! RTX_FRAME_RELATED_P (insn) = 1; ! body = PATTERN (insn); ! if (GET_CODE (body) == PARALLEL) ! for (i = 0; i < XVECLEN (body, 0); i++) ! RTX_FRAME_RELATED_P (XVECEXP (body, 0, i)) = 1; ! } ! ! /* Emit RTL for the "prologue" define_expand. */ ! ! void ! m68k_expand_prologue (void) { HOST_WIDE_INT fsize_with_regs; ! rtx limit, src, dest, insn; ! m68k_compute_frame_layout (); /* If the stack limit is a symbol, we can check it here, before actually allocating the space. */ if (current_function_limit_stack && GET_CODE (stack_limit_rtx) == SYMBOL_REF) ! { ! limit = plus_constant (stack_limit_rtx, current_frame.size + 4); ! if (!LEGITIMATE_CONSTANT_P (limit)) ! { ! emit_move_insn (gen_rtx_REG (Pmode, D0_REG), limit); ! limit = gen_rtx_REG (Pmode, D0_REG); ! } ! emit_insn (gen_cmpsi (stack_pointer_rtx, limit)); ! emit_insn (gen_conditional_trap (gen_rtx_LTU (VOIDmode, ! cc0_rtx, const0_rtx), ! const1_rtx)); ! } fsize_with_regs = current_frame.size; if (TARGET_COLDFIRE) { ! /* ColdFire's move multiple instructions do not allow pre-decrement ! addressing. Add the size of movem saves to the initial stack ! allocation instead. */ ! if (current_frame.reg_no >= MIN_MOVEM_REGS) ! fsize_with_regs += current_frame.reg_no * GET_MODE_SIZE (SImode); ! if (current_frame.fpu_no >= MIN_FMOVEM_REGS) ! fsize_with_regs += current_frame.fpu_no * GET_MODE_SIZE (DFmode); } if (frame_pointer_needed) { ! if (fsize_with_regs == 0 && TUNE_68040) { ! /* On the 68040, two separate moves are faster than link.w 0. */ ! dest = gen_frame_mem (Pmode, ! gen_rtx_PRE_DEC (Pmode, stack_pointer_rtx)); ! m68k_set_frame_related (emit_move_insn (dest, frame_pointer_rtx)); ! m68k_set_frame_related (emit_move_insn (frame_pointer_rtx, ! stack_pointer_rtx)); ! } ! else if (fsize_with_regs < 0x8000 || TARGET_68020) ! m68k_set_frame_related ! (emit_insn (gen_link (frame_pointer_rtx, ! GEN_INT (-4 - fsize_with_regs)))); else ! { ! m68k_set_frame_related ! (emit_insn (gen_link (frame_pointer_rtx, GEN_INT (-4)))); ! m68k_set_frame_related ! (emit_insn (gen_addsi3 (stack_pointer_rtx, ! stack_pointer_rtx, ! GEN_INT (-fsize_with_regs)))); ! } } + else if (fsize_with_regs != 0) + m68k_set_frame_related + (emit_insn (gen_addsi3 (stack_pointer_rtx, + stack_pointer_rtx, + GEN_INT (-fsize_with_regs)))); if (current_frame.fpu_mask) { + gcc_assert (current_frame.fpu_no >= MIN_FMOVEM_REGS); if (TARGET_68881) ! m68k_set_frame_related ! (m68k_emit_movem (stack_pointer_rtx, ! current_frame.fpu_no * -GET_MODE_SIZE (XFmode), ! current_frame.fpu_no, FP0_REG, ! current_frame.fpu_mask, true, true)); else { int offset; ! /* If we're using moveml to save the integer registers, ! the stack pointer will point to the bottom of the moveml ! save area. Find the stack offset of the first FP register. */ ! if (current_frame.reg_no < MIN_MOVEM_REGS) offset = 0; else ! offset = current_frame.reg_no * GET_MODE_SIZE (SImode); ! m68k_set_frame_related ! (m68k_emit_movem (stack_pointer_rtx, offset, ! current_frame.fpu_no, FP0_REG, ! current_frame.fpu_mask, true, false)); } } *************** m68k_output_function_prologue (FILE *str *** 950,1045 **** if (current_function_limit_stack) { if (REG_P (stack_limit_rtx)) ! asm_fprintf (stream, "\tcmp" ASM_DOT "l %s,%Rsp\n\ttrapcs\n", ! M68K_REGNAME (REGNO (stack_limit_rtx))); else if (GET_CODE (stack_limit_rtx) != SYMBOL_REF) warning (0, "stack limit expression is not supported"); } ! if (current_frame.reg_no <= 2) { ! /* Store each separately in the same order moveml uses. ! Using two movel instructions instead of a single moveml ! is about 15% faster for the 68020 and 68030 at no expense ! in code size. */ ! int i; ! for (i = 0; i < 16; i++) ! if (current_frame.reg_rev_mask & (1 << i)) { ! asm_fprintf (stream, (MOTOROLA ! ? "\t%Omove.l %s,-(%Rsp)\n" ! : "\tmovel %s,%Rsp@-\n"), ! M68K_REGNAME (15 - i)); ! if (dwarf2out_do_frame ()) ! { ! char *l = (char *) dwarf2out_cfi_label (); ! ! cfa_offset += 4; ! if (! frame_pointer_needed) ! dwarf2out_def_cfa (l, STACK_POINTER_REGNUM, cfa_offset); ! dwarf2out_reg_save (l, 15 - i, -cfa_offset); ! } } } ! else if (current_frame.reg_rev_mask) { if (TARGET_COLDFIRE) ! /* The ColdFire does not support the predecrement form of the ! MOVEM instruction, so we must adjust the stack pointer and ! then use the plain address register indirect mode. ! The required register save space was combined earlier with ! the fsize_with_regs amount. */ ! ! asm_fprintf (stream, (MOTOROLA ! ? "\tmovm.l %I0x%x,(%Rsp)\n" ! : "\tmoveml %I0x%x,%Rsp@\n"), ! current_frame.reg_mask); ! else ! asm_fprintf (stream, (MOTOROLA ! ? "\tmovm.l %I0x%x,-(%Rsp)\n" ! : "\tmoveml %I0x%x,%Rsp@-\n"), ! current_frame.reg_rev_mask); ! if (dwarf2out_do_frame ()) ! { ! char *l = (char *) dwarf2out_cfi_label (); ! int n_regs, regno; ! ! cfa_offset += current_frame.reg_no * 4; ! if (! frame_pointer_needed) ! dwarf2out_def_cfa (l, STACK_POINTER_REGNUM, cfa_offset); ! for (regno = 0, n_regs = 0; regno < 16; regno++) ! if (current_frame.reg_mask & (1 << regno)) ! dwarf2out_reg_save (l, regno, -cfa_offset + n_regs++ * 4); ! } } ! if (!TARGET_SEP_DATA && flag_pic && (current_function_uses_pic_offset_table || (!current_function_is_leaf && TARGET_ID_SHARED_LIBRARY))) { ! if (TARGET_ID_SHARED_LIBRARY) ! { ! asm_fprintf (stream, "\tmovel %s@(%s), %s\n", ! M68K_REGNAME (PIC_OFFSET_TABLE_REGNUM), ! m68k_library_id_string, ! M68K_REGNAME (PIC_OFFSET_TABLE_REGNUM)); ! } ! else ! { ! if (MOTOROLA) ! asm_fprintf (stream, ! "\t%Olea (%Rpc, %U_GLOBAL_OFFSET_TABLE_@GOTPC), %s\n", ! M68K_REGNAME (PIC_OFFSET_TABLE_REGNUM)); ! else ! { ! asm_fprintf (stream, "\tmovel %I%U_GLOBAL_OFFSET_TABLE_, %s\n", ! M68K_REGNAME (PIC_OFFSET_TABLE_REGNUM)); ! asm_fprintf (stream, "\tlea %Rpc@(0,%s:l),%s\n", ! M68K_REGNAME (PIC_OFFSET_TABLE_REGNUM), ! M68K_REGNAME (PIC_OFFSET_TABLE_REGNUM)); ! } ! } } } \f --- 950,1005 ---- if (current_function_limit_stack) { if (REG_P (stack_limit_rtx)) ! { ! emit_insn (gen_cmpsi (stack_pointer_rtx, stack_limit_rtx)); ! emit_insn (gen_conditional_trap (gen_rtx_LTU (VOIDmode, ! cc0_rtx, const0_rtx), ! const1_rtx)); ! } else if (GET_CODE (stack_limit_rtx) != SYMBOL_REF) warning (0, "stack limit expression is not supported"); } ! if (current_frame.reg_no < MIN_MOVEM_REGS) { ! /* Store each register separately in the same order moveml does. */ int i; ! for (i = 16; i-- > 0; ) ! if (current_frame.reg_mask & (1 << i)) { ! src = gen_rtx_REG (SImode, D0_REG + i); ! dest = gen_frame_mem (SImode, ! gen_rtx_PRE_DEC (Pmode, stack_pointer_rtx)); ! m68k_set_frame_related (emit_insn (gen_movsi (dest, src))); } } ! else { if (TARGET_COLDFIRE) ! /* The required register save space has already been allocated. ! The first register should be stored at (%sp). */ ! m68k_set_frame_related ! (m68k_emit_movem (stack_pointer_rtx, 0, ! current_frame.reg_no, D0_REG, ! current_frame.reg_mask, true, false)); ! else ! m68k_set_frame_related ! (m68k_emit_movem (stack_pointer_rtx, ! current_frame.reg_no * -GET_MODE_SIZE (SImode), ! current_frame.reg_no, D0_REG, ! current_frame.reg_mask, true, true)); } ! ! if (flag_pic ! && !TARGET_SEP_DATA && (current_function_uses_pic_offset_table || (!current_function_is_leaf && TARGET_ID_SHARED_LIBRARY))) { ! insn = emit_insn (gen_load_got (pic_offset_table_rtx)); ! REG_NOTES (insn) = gen_rtx_EXPR_LIST (REG_MAYBE_DEAD, ! const0_rtx, ! REG_NOTES (insn)); } } \f *************** m68k_use_return_insn (void) *** 1056,1356 **** return current_frame.offset == 0; } ! /* This function generates the assembly code for function exit, ! on machines that need it. The function epilogue should not depend on the current stack pointer! It should use the frame pointer only, if there is a frame pointer. This is mandatory because of alloca; we also take advantage of it to omit stack adjustments before returning. */ ! static void ! m68k_output_function_epilogue (FILE *stream, ! HOST_WIDE_INT size ATTRIBUTE_UNUSED) { HOST_WIDE_INT fsize, fsize_with_regs; ! bool big = false; ! bool restore_from_sp = false; ! rtx insn = get_last_insn (); m68k_compute_frame_layout (); - /* If the last insn was a BARRIER, we don't have to write any code. */ - if (GET_CODE (insn) == NOTE) - insn = prev_nonnote_insn (insn); - if (insn && GET_CODE (insn) == BARRIER) - return; - fsize = current_frame.size; ! /* FIXME: leaf_function_p below is too strong. What we really need to know there is if there could be pending stack adjustment needed at that point. */ ! restore_from_sp ! = (! frame_pointer_needed ! || (! current_function_calls_alloca && leaf_function_p ())); /* fsize_with_regs is the size we need to adjust the sp when popping the frame. */ fsize_with_regs = fsize; - - /* Because the ColdFire doesn't support moveml with - complex address modes, we must adjust the stack manually - after restoring registers. When the frame pointer isn't used, - we can merge movem adjustment into frame unlinking - made immediately after it. */ if (TARGET_COLDFIRE && restore_from_sp) { ! if (current_frame.reg_no > 2) ! fsize_with_regs += current_frame.reg_no * 4; ! if (current_frame.fpu_no) ! fsize_with_regs += current_frame.fpu_no * 8; } if (current_frame.offset + fsize >= 0x8000 ! && ! restore_from_sp && (current_frame.reg_mask || current_frame.fpu_mask)) { ! /* Because the ColdFire doesn't support moveml with ! complex address modes we make an extra correction here. */ ! if (TARGET_COLDFIRE) ! fsize += current_frame.offset; ! ! asm_fprintf (stream, "\t%Omove" ASM_DOT "l %I%wd,%Ra1\n", -fsize); ! fsize = 0, big = true; } - if (current_frame.reg_no <= 2) - { - /* Restore each separately in the same order moveml does. - Using two movel instructions instead of a single moveml - is about 15% faster for the 68020 and 68030 at no expense - in code size. */ int i; ! HOST_WIDE_INT offset = current_frame.offset + fsize; for (i = 0; i < 16; i++) if (current_frame.reg_mask & (1 << i)) { ! if (big) ! { ! if (MOTOROLA) ! asm_fprintf (stream, "\t%Omove.l -%wd(%s,%Ra1.l),%s\n", ! offset, ! M68K_REGNAME (FRAME_POINTER_REGNUM), ! M68K_REGNAME (i)); ! else ! asm_fprintf (stream, "\tmovel %s@(-%wd,%Ra1:l),%s\n", ! M68K_REGNAME (FRAME_POINTER_REGNUM), ! offset, ! M68K_REGNAME (i)); ! } ! else if (restore_from_sp) ! asm_fprintf (stream, (MOTOROLA ! ? "\t%Omove.l (%Rsp)+,%s\n" ! : "\tmovel %Rsp@+,%s\n"), ! M68K_REGNAME (i)); ! else { ! if (MOTOROLA) ! asm_fprintf (stream, "\t%Omove.l -%wd(%s),%s\n", ! offset, ! M68K_REGNAME (FRAME_POINTER_REGNUM), ! M68K_REGNAME (i)); ! else ! asm_fprintf (stream, "\tmovel %s@(-%wd),%s\n", ! M68K_REGNAME (FRAME_POINTER_REGNUM), ! offset, ! M68K_REGNAME (i)); } ! offset -= 4; ! } } else if (current_frame.reg_mask) { ! /* The ColdFire requires special handling due to its limited moveml ! insn. */ ! if (TARGET_COLDFIRE) ! { ! if (big) ! { ! asm_fprintf (stream, "\tadd" ASM_DOT "l %s,%Ra1\n", ! M68K_REGNAME (FRAME_POINTER_REGNUM)); ! asm_fprintf (stream, (MOTOROLA ! ? "\tmovm.l (%Ra1),%I0x%x\n" ! : "\tmoveml %Ra1@,%I0x%x\n"), ! current_frame.reg_mask); ! } ! else if (restore_from_sp) ! asm_fprintf (stream, (MOTOROLA ! ? "\tmovm.l (%Rsp),%I0x%x\n" ! : "\tmoveml %Rsp@,%I0x%x\n"), ! current_frame.reg_mask); ! else ! { ! if (MOTOROLA) ! asm_fprintf (stream, "\tmovm.l -%wd(%s),%I0x%x\n", ! current_frame.offset + fsize, ! M68K_REGNAME (FRAME_POINTER_REGNUM), ! current_frame.reg_mask); ! else ! asm_fprintf (stream, "\tmoveml %s@(-%wd),%I0x%x\n", ! M68K_REGNAME (FRAME_POINTER_REGNUM), ! current_frame.offset + fsize, ! current_frame.reg_mask); ! } ! } ! else /* !TARGET_COLDFIRE */ ! { ! if (big) ! { ! if (MOTOROLA) ! asm_fprintf (stream, "\tmovm.l -%wd(%s,%Ra1.l),%I0x%x\n", ! current_frame.offset + fsize, ! M68K_REGNAME (FRAME_POINTER_REGNUM), ! current_frame.reg_mask); ! else ! asm_fprintf (stream, "\tmoveml %s@(-%wd,%Ra1:l),%I0x%x\n", ! M68K_REGNAME (FRAME_POINTER_REGNUM), ! current_frame.offset + fsize, ! current_frame.reg_mask); ! } ! else if (restore_from_sp) ! { ! asm_fprintf (stream, (MOTOROLA ! ? "\tmovm.l (%Rsp)+,%I0x%x\n" ! : "\tmoveml %Rsp@+,%I0x%x\n"), ! current_frame.reg_mask); ! } ! else ! { ! if (MOTOROLA) ! asm_fprintf (stream, "\tmovm.l -%wd(%s),%I0x%x\n", ! current_frame.offset + fsize, ! M68K_REGNAME (FRAME_POINTER_REGNUM), ! current_frame.reg_mask); ! else ! asm_fprintf (stream, "\tmoveml %s@(-%wd),%I0x%x\n", ! M68K_REGNAME (FRAME_POINTER_REGNUM), ! current_frame.offset + fsize, ! current_frame.reg_mask); ! } ! } } ! if (current_frame.fpu_rev_mask) { if (big) ! { ! if (TARGET_COLDFIRE) ! { ! if (current_frame.reg_no) ! asm_fprintf (stream, MOTOROLA ? ! "\tfmovem.d %d(%Ra1),%I0x%x\n" : ! "\tfmovmd (%d,%Ra1),%I0x%x\n", ! current_frame.reg_no * 4, ! current_frame.fpu_rev_mask); ! else ! asm_fprintf (stream, MOTOROLA ? ! "\tfmovem.d (%Ra1),%I0x%x\n" : ! "\tfmovmd (%Ra1),%I0x%x\n", ! current_frame.fpu_rev_mask); ! } ! else if (MOTOROLA) ! asm_fprintf (stream, "\tfmovm -%wd(%s,%Ra1.l),%I0x%x\n", ! current_frame.foffset + fsize, ! M68K_REGNAME (FRAME_POINTER_REGNUM), ! current_frame.fpu_rev_mask); ! else ! asm_fprintf (stream, "\tfmovem %s@(-%wd,%Ra1:l),%I0x%x\n", ! M68K_REGNAME (FRAME_POINTER_REGNUM), ! current_frame.foffset + fsize, ! current_frame.fpu_rev_mask); ! } else if (restore_from_sp) { if (TARGET_COLDFIRE) { int offset; ! /* Stack already has registers in it. Find the offset from ! the bottom of stack to where the FP registers go. */ ! if (current_frame.reg_no <= 2) offset = 0; else ! offset = current_frame.reg_no * 4; ! if (offset) ! asm_fprintf (stream, ! "\tfmovem %Rsp@(%d), %I0x%x\n", ! offset, current_frame.fpu_rev_mask); ! else ! asm_fprintf (stream, ! "\tfmovem %Rsp@, %I0x%x\n", ! current_frame.fpu_rev_mask); } else ! asm_fprintf (stream, MOTOROLA ? ! "\tfmovm (%Rsp)+,%I0x%x\n" : ! "\tfmovem %Rsp@+,%I0x%x\n", ! current_frame.fpu_rev_mask); } else ! { ! if (MOTOROLA && !TARGET_COLDFIRE) ! asm_fprintf (stream, "\tfmovm -%wd(%s),%I0x%x\n", ! current_frame.foffset + fsize, ! M68K_REGNAME (FRAME_POINTER_REGNUM), ! current_frame.fpu_rev_mask); ! else ! asm_fprintf (stream, "\tfmovem %s@(-%wd),%I0x%x\n", ! M68K_REGNAME (FRAME_POINTER_REGNUM), ! current_frame.foffset + fsize, ! current_frame.fpu_rev_mask); ! } } if (frame_pointer_needed) ! fprintf (stream, "\tunlk %s\n", M68K_REGNAME (FRAME_POINTER_REGNUM)); else if (fsize_with_regs) ! { ! if (fsize_with_regs <= 8) ! { ! if (!TARGET_COLDFIRE) ! asm_fprintf (stream, "\taddq" ASM_DOT "w %I%wd,%Rsp\n", ! fsize_with_regs); ! else ! asm_fprintf (stream, "\taddq" ASM_DOT "l %I%wd,%Rsp\n", ! fsize_with_regs); ! } ! else if (fsize_with_regs <= 16 && TUNE_CPU32) ! { ! /* On the CPU32 it is faster to use two addqw instructions to ! add a small integer (8 < N <= 16) to a register. */ ! asm_fprintf (stream, ! "\taddq" ASM_DOT "w %I8,%Rsp\n" ! "\taddq" ASM_DOT "w %I%wd,%Rsp\n", ! fsize_with_regs - 8); ! } ! else if (fsize_with_regs < 0x8000) ! { ! if (TUNE_68040) ! asm_fprintf (stream, "\tadd" ASM_DOT "w %I%wd,%Rsp\n", ! fsize_with_regs); ! else ! asm_fprintf (stream, (MOTOROLA ! ? "\tlea (%wd,%Rsp),%Rsp\n" ! : "\tlea %Rsp@(%wd),%Rsp\n"), ! fsize_with_regs); ! } ! else ! asm_fprintf (stream, "\tadd" ASM_DOT "l %I%wd,%Rsp\n", fsize_with_regs); ! } if (current_function_calls_eh_return) ! asm_fprintf (stream, "\tadd" ASM_DOT "l %Ra0,%Rsp\n"); ! if (m68k_interrupt_function_p (current_function_decl)) ! fprintf (stream, "\trte\n"); ! else if (current_function_pops_args) ! asm_fprintf (stream, "\trtd %I%d\n", current_function_pops_args); ! else ! fprintf (stream, "\trts\n"); } \f /* Return true if X is a valid comparison operator for the dbcc --- 1016,1188 ---- return current_frame.offset == 0; } ! /* Emit RTL for the "epilogue" define_expand. The function epilogue should not depend on the current stack pointer! It should use the frame pointer only, if there is a frame pointer. This is mandatory because of alloca; we also take advantage of it to omit stack adjustments before returning. */ ! void ! m68k_expand_epilogue (void) { HOST_WIDE_INT fsize, fsize_with_regs; ! bool big, restore_from_sp; m68k_compute_frame_layout (); fsize = current_frame.size; + big = false; + restore_from_sp = false; ! /* FIXME : current_function_is_leaf below is too strong. What we really need to know there is if there could be pending stack adjustment needed at that point. */ ! restore_from_sp = (!frame_pointer_needed ! || (!current_function_calls_alloca ! && current_function_is_leaf)); /* fsize_with_regs is the size we need to adjust the sp when popping the frame. */ fsize_with_regs = fsize; if (TARGET_COLDFIRE && restore_from_sp) { ! /* ColdFire's move multiple instructions do not allow post-increment ! addressing. Add the size of movem loads to the final deallocation ! instead. */ ! if (current_frame.reg_no >= MIN_MOVEM_REGS) ! fsize_with_regs += current_frame.reg_no * GET_MODE_SIZE (SImode); ! if (current_frame.fpu_no >= MIN_FMOVEM_REGS) ! fsize_with_regs += current_frame.fpu_no * GET_MODE_SIZE (DFmode); } if (current_frame.offset + fsize >= 0x8000 ! && !restore_from_sp && (current_frame.reg_mask || current_frame.fpu_mask)) { ! if (TARGET_COLDFIRE ! && (current_frame.reg_no >= MIN_MOVEM_REGS ! || current_frame.fpu_no >= MIN_FMOVEM_REGS)) ! { ! /* ColdFire's move multiple instructions do not support the ! (d8,Ax,Xi) addressing mode, so we're as well using a normal ! stack-based restore. */ ! emit_move_insn (gen_rtx_REG (Pmode, A1_REG), ! GEN_INT (-(current_frame.offset + fsize))); ! emit_insn (gen_addsi3 (stack_pointer_rtx, ! gen_rtx_REG (Pmode, A1_REG), ! frame_pointer_rtx)); ! restore_from_sp = true; ! } ! else ! { ! emit_move_insn (gen_rtx_REG (Pmode, A1_REG), GEN_INT (-fsize)); ! fsize = 0; ! big = true; ! } } + if (current_frame.reg_no < MIN_MOVEM_REGS) + { + /* Restore each register separately in the same order moveml does. */ int i; ! HOST_WIDE_INT offset; + offset = current_frame.offset + fsize; for (i = 0; i < 16; i++) if (current_frame.reg_mask & (1 << i)) { ! rtx addr; ! ! if (big) { ! /* Generate the address -OFFSET(%fp,%a1.l). */ ! addr = gen_rtx_REG (Pmode, A1_REG); ! addr = gen_rtx_PLUS (Pmode, addr, frame_pointer_rtx); ! addr = plus_constant (addr, -offset); } ! else if (restore_from_sp) ! addr = gen_rtx_POST_INC (Pmode, stack_pointer_rtx); ! else ! addr = plus_constant (frame_pointer_rtx, -offset); ! emit_move_insn (gen_rtx_REG (SImode, D0_REG + i), ! gen_frame_mem (SImode, addr)); ! offset -= GET_MODE_SIZE (SImode); ! } } else if (current_frame.reg_mask) { ! if (big) ! m68k_emit_movem (gen_rtx_PLUS (Pmode, ! gen_rtx_REG (Pmode, A1_REG), ! frame_pointer_rtx), ! -(current_frame.offset + fsize), ! current_frame.reg_no, D0_REG, ! current_frame.reg_mask, false, false); ! else if (restore_from_sp) ! m68k_emit_movem (stack_pointer_rtx, 0, ! current_frame.reg_no, D0_REG, ! current_frame.reg_mask, false, ! !TARGET_COLDFIRE); ! else ! m68k_emit_movem (frame_pointer_rtx, ! -(current_frame.offset + fsize), ! current_frame.reg_no, D0_REG, ! current_frame.reg_mask, false, false); } ! ! if (current_frame.fpu_no > 0) { if (big) ! m68k_emit_movem (gen_rtx_PLUS (Pmode, ! gen_rtx_REG (Pmode, A1_REG), ! frame_pointer_rtx), ! -(current_frame.foffset + fsize), ! current_frame.fpu_no, FP0_REG, ! current_frame.fpu_mask, false, false); else if (restore_from_sp) { if (TARGET_COLDFIRE) { int offset; ! /* If we used moveml to restore the integer registers, the ! stack pointer will still point to the bottom of the moveml ! save area. Find the stack offset of the first FP ! register. */ ! if (current_frame.reg_no < MIN_MOVEM_REGS) offset = 0; else ! offset = current_frame.reg_no * GET_MODE_SIZE (SImode); ! m68k_emit_movem (stack_pointer_rtx, offset, ! current_frame.fpu_no, FP0_REG, ! current_frame.fpu_mask, false, false); } else ! m68k_emit_movem (stack_pointer_rtx, 0, ! current_frame.fpu_no, FP0_REG, ! current_frame.fpu_mask, false, true); } else ! m68k_emit_movem (frame_pointer_rtx, ! -(current_frame.foffset + fsize), ! current_frame.fpu_no, FP0_REG, ! current_frame.fpu_mask, false, false); } + if (frame_pointer_needed) ! emit_insn (gen_unlink (frame_pointer_rtx)); else if (fsize_with_regs) ! emit_insn (gen_addsi3 (stack_pointer_rtx, ! stack_pointer_rtx, ! GEN_INT (fsize_with_regs))); ! if (current_function_calls_eh_return) ! emit_insn (gen_addsi3 (stack_pointer_rtx, ! stack_pointer_rtx, ! EH_RETURN_STACKADJ_RTX)); ! ! emit_insn (gen_rtx_RETURN (VOIDmode)); } \f /* Return true if X is a valid comparison operator for the dbcc *************** emit_move_sequence (rtx *operands, enum *** 3087,3092 **** --- 2919,3122 ---- return 0; } + /* Split X into a base and a constant offset, storing them in *BASE + and *OFFSET respectively. */ + + static void + m68k_split_offset (rtx x, rtx *base, HOST_WIDE_INT *offset) + { + *offset = 0; + if (GET_CODE (x) == PLUS && GET_CODE (XEXP (x, 1)) == CONST_INT) + { + *offset += INTVAL (XEXP (x, 1)); + x = XEXP (x, 0); + } + *base = x; + } + + /* Return true if PATTERN is a PARALLEL suitable for a movem or fmovem + instruction. STORE_P says whether the move is a load or store. + + If the instruction uses post-increment or pre-decrement addressing, + AUTOMOD_BASE is the base register and AUTOMOD_OFFSET is the total + adjustment. This adjustment will be made by the first element of + PARALLEL, with the loads or stores starting at element 1. If the + instruction does not use post-increment or pre-decrement addressing, + AUTOMOD_BASE is null, AUTOMOD_OFFSET is 0, and the loads or stores + start at element 0. */ + + bool + m68k_movem_pattern_p (rtx pattern, rtx automod_base, + HOST_WIDE_INT automod_offset, bool store_p) + { + rtx base, mem_base, set, mem, reg, last_reg; + HOST_WIDE_INT offset, mem_offset; + int i, first, len; + enum reg_class rclass; + + len = XVECLEN (pattern, 0); + first = (automod_base != NULL); + + if (automod_base) + { + /* Stores must be pre-decrement and loads must be post-increment. */ + if (store_p != (automod_offset < 0)) + return false; + + /* Work out the base and offset for lowest memory location. */ + base = automod_base; + offset = (automod_offset < 0 ? automod_offset : 0); + } + else + { + /* Allow any valid base and offset in the first access. */ + base = NULL; + offset = 0; + } + + last_reg = NULL; + rclass = NO_REGS; + for (i = first; i < len; i++) + { + /* We need a plain SET. */ + set = XVECEXP (pattern, 0, i); + if (GET_CODE (set) != SET) + return false; + + /* Check that we have a memory location... */ + mem = XEXP (set, !store_p); + if (!MEM_P (mem) || !memory_operand (mem, VOIDmode)) + return false; + + /* ...with the right address. */ + if (base == NULL) + { + m68k_split_offset (XEXP (mem, 0), &base, &offset); + /* The ColdFire instruction only allows (An) and (d16,An) modes. + There are no mode restrictions for 680x0 besides the + automodification rules enforced above. */ + if (TARGET_COLDFIRE + && !m68k_legitimate_base_reg_p (base, reload_completed)) + return false; + } + else + { + m68k_split_offset (XEXP (mem, 0), &mem_base, &mem_offset); + if (!rtx_equal_p (base, mem_base) || offset != mem_offset) + return false; + } + + /* Check that we have a register of the required mode and class. */ + reg = XEXP (set, store_p); + if (!REG_P (reg) + || !HARD_REGISTER_P (reg) + || GET_MODE (reg) != reg_raw_mode[REGNO (reg)]) + return false; + + if (last_reg) + { + /* The register must belong to RCLASS and have a higher number + than the register in the previous SET. */ + if (!TEST_HARD_REG_BIT (reg_class_contents[rclass], REGNO (reg)) + || REGNO (last_reg) >= REGNO (reg)) + return false; + } + else + { + /* Work out which register class we need. */ + if (INT_REGNO_P (REGNO (reg))) + rclass = GENERAL_REGS; + else if (FP_REGNO_P (REGNO (reg))) + rclass = FP_REGS; + else + return false; + } + + last_reg = reg; + offset += GET_MODE_SIZE (GET_MODE (reg)); + } + + /* If we have an automodification, check whether the final offset is OK. */ + if (automod_base && offset != (automod_offset < 0 ? 0 : automod_offset)) + return false; + + /* Reject unprofitable cases. */ + if (len < first + (rclass == FP_REGS ? MIN_FMOVEM_REGS : MIN_MOVEM_REGS)) + return false; + + return true; + } + + /* Return the assembly code template for a movem or fmovem instruction + whose pattern is given by PATTERN. Store the template's operands + in OPERANDS. + + If the instruction uses post-increment or pre-decrement addressing, + AUTOMOD_OFFSET is the total adjustment, otherwise it is 0. STORE_P + is true if this is a store instruction. */ + + const char * + m68k_output_movem (rtx *operands, rtx pattern, + HOST_WIDE_INT automod_offset, bool store_p) + { + unsigned int mask; + int i, first; + + gcc_assert (GET_CODE (pattern) == PARALLEL); + mask = 0; + first = (automod_offset != 0); + for (i = first; i < XVECLEN (pattern, 0); i++) + { + /* When using movem with pre-decrement addressing, register X + D0_REG + is controlled by bit 15 - X. For all other addressing modes, + register X + D0_REG is controlled by bit X. Confusingly, the + register mask for fmovem is in the opposite order to that for + movem. */ + unsigned int regno; + + gcc_assert (MEM_P (XEXP (XVECEXP (pattern, 0, i), !store_p))); + gcc_assert (REG_P (XEXP (XVECEXP (pattern, 0, i), store_p))); + regno = REGNO (XEXP (XVECEXP (pattern, 0, i), store_p)); + if (automod_offset < 0) + { + if (FP_REGNO_P (regno)) + mask |= 1 << (regno - FP0_REG); + else + mask |= 1 << (15 - (regno - D0_REG)); + } + else + { + if (FP_REGNO_P (regno)) + mask |= 1 << (7 - (regno - FP0_REG)); + else + mask |= 1 << (regno - D0_REG); + } + } + CC_STATUS_INIT; + + if (automod_offset == 0) + operands[0] = XEXP (XEXP (XVECEXP (pattern, 0, first), !store_p), 0); + else if (automod_offset < 0) + operands[0] = gen_rtx_PRE_DEC (Pmode, SET_DEST (XVECEXP (pattern, 0, 0))); + else + operands[0] = gen_rtx_POST_INC (Pmode, SET_DEST (XVECEXP (pattern, 0, 0))); + operands[1] = GEN_INT (mask); + if (FP_REGNO_P (REGNO (XEXP (XVECEXP (pattern, 0, first), store_p)))) + { + if (store_p) + return MOTOROLA ? "fmovm %1,%a0" : "fmovem %1,%a0"; + else + return MOTOROLA ? "fmovm %a0,%1" : "fmovem %a0,%1"; + } + else + { + if (store_p) + return MOTOROLA ? "movm.l %1,%a0" : "moveml %1,%a0"; + else + return MOTOROLA ? "movm.l %a0,%1" : "moveml %a0,%1"; + } + } + /* Return a REG that occurs in ADDR with coefficient 1. ADDR can be effectively incremented by incrementing REG. */ *************** floating_exact_log2 (rtx x) *** 3452,3457 **** --- 3482,3488 ---- '$' for the letter `s' in an op code, but only on the 68040. '&' for the letter `d' in an op code, but only on the 68040. '/' for register prefix needed by longlong.h. + '?' for m68k_library_id_string 'b' for byte insn (no effect, on the Sun; this is for the ISI). 'd' to force memory addressing to be absolute, not relative. *************** print_operand (FILE *file, rtx op, int l *** 3491,3496 **** --- 3522,3529 ---- } else if (letter == '/') asm_fprintf (file, "%R"); + else if (letter == '?') + asm_fprintf (file, m68k_library_id_string); else if (letter == 'p') { output_addr_const (file, op); Index: gcc/config/m68k/m68k.md =================================================================== *** gcc/config/m68k/m68k.md 2007-01-09 15:02:13.000000000 +0000 --- gcc/config/m68k/m68k.md 2007-01-09 15:02:15.000000000 +0000 *************** *** 112,119 **** ;; UNSPEC usage: (define_constants ! [(UNSPEC_SIN 1) ! (UNSPEC_COS 2) ]) ;; UNSPEC_VOLATILE usage: --- 112,120 ---- ;; UNSPEC usage: (define_constants ! [(UNSPEC_SIN 1) ! (UNSPEC_COS 2) ! (UNSPEC_GOT 3) ]) ;; UNSPEC_VOLATILE usage: *************** (define_constants *** 126,132 **** --- 127,136 ---- (define_constants [(D0_REG 0) (A0_REG 8) + (A1_REG 9) + (PIC_REG 13) (SP_REG 15) + (FP0_REG 16) ]) (include "predicates.md") *************** (define_insn "nop" *** 6465,6479 **** "" "nop") ;; Used for frameless functions which save no regs and allocate no locals. ! (define_insn "return" [(return)] "m68k_use_return_insn ()" { ! if (current_function_pops_args == 0) return "rts"; ! operands[0] = GEN_INT (current_function_pops_args); ! return "rtd %0"; }) (define_insn "indirect_jump" --- 6469,6626 ---- "" "nop") + (define_expand "prologue" + [(const_int 0)] + "" + { + m68k_expand_prologue (); + DONE; + }) + + (define_expand "epilogue" + [(return)] + "" + { + m68k_expand_epilogue (); + DONE; + }) + ;; Used for frameless functions which save no regs and allocate no locals. ! (define_expand "return" [(return)] "m68k_use_return_insn ()" + "") + + (define_insn "*return" + [(return)] + "" { ! if (m68k_interrupt_function_p (current_function_decl)) ! return "rte"; ! else if (current_function_pops_args) ! { ! operands[0] = GEN_INT (current_function_pops_args); ! return "rtd %0"; ! } ! else return "rts"; ! }) ! ! (define_insn "*m68k_store_multiple" ! [(match_parallel 0 "" [(match_operand 1 "")])] ! "m68k_movem_pattern_p (operands[0], NULL, 0, true)" ! { ! return m68k_output_movem (operands, operands[0], 0, true); ! }) ! ! (define_insn "*m68k_store_multiple_automod" ! [(match_parallel 0 "" ! [(set (match_operand:SI 1 "register_operand" "=a") ! (plus:SI (match_operand:SI 2 "register_operand" "1") ! (match_operand:SI 3 "const_int_operand")))])] ! "m68k_movem_pattern_p (operands[0], operands[1], INTVAL (operands[3]), true)" ! { ! return m68k_output_movem (operands, operands[0], INTVAL (operands[3]), true); ! }) ! ! (define_insn "*m68k_load_multiple" ! [(match_parallel 0 "" [(match_operand 1 "")])] ! "m68k_movem_pattern_p (operands[0], NULL, 0, false)" ! { ! return m68k_output_movem (operands, operands[0], 0, false); ! }) ! ! (define_insn "*m68k_load_multiple_automod" ! [(match_parallel 0 "" ! [(set (match_operand:SI 1 "register_operand" "=a") ! (plus:SI (match_operand:SI 2 "register_operand" "1") ! (match_operand:SI 3 "const_int_operand")))])] ! "m68k_movem_pattern_p (operands[0], operands[1], ! INTVAL (operands[3]), false)" ! { ! return m68k_output_movem (operands, operands[0], ! INTVAL (operands[3]), false); ! }) ! ! (define_expand "link" ! [(parallel ! [(set (match_operand:SI 0 "register_operand") ! (plus:SI (reg:SI SP_REG) (const_int -4))) ! (set (match_dup 2) ! (match_dup 0)) ! (set (reg:SI SP_REG) ! (plus:SI (reg:SI SP_REG) ! (match_operand:SI 1 "const_int_operand")))])] ! "TARGET_68020 || INTVAL (operands[1]) >= -0x8004" ! { ! operands[2] = gen_frame_mem (SImode, plus_constant (stack_pointer_rtx, -4)); ! }) ! ! (define_insn "*link" ! [(set (match_operand:SI 0 "register_operand" "+r") ! (plus:SI (reg:SI SP_REG) (const_int -4))) ! (set (mem:SI (plus:SI (reg:SI SP_REG) (const_int -4))) ! (match_dup 0)) ! (set (reg:SI SP_REG) ! (plus:SI (reg:SI SP_REG) ! (match_operand:SI 1 "const_int_operand")))] ! "TARGET_68020 || INTVAL (operands[1]) >= -0x8004" ! { ! operands[1] = GEN_INT (INTVAL (operands[1]) + 4); ! if (!MOTOROLA) ! return "link %0,%1"; ! else if (INTVAL (operands[1]) >= -0x8000) ! return "link.w %0,%1"; ! else ! return "link.l %0,%1"; ! }) ! ! (define_expand "unlink" ! [(parallel ! [(set (match_operand:SI 0 "register_operand") ! (match_dup 1)) ! (set (reg:SI SP_REG) ! (plus:SI (match_dup 0) ! (const_int 4)))])] ! "" ! { ! operands[1] = gen_frame_mem (SImode, copy_rtx (operands[0])); ! }) ! ! (define_insn "*unlink" ! [(set (match_operand:SI 0 "register_operand" "+r") ! (mem:SI (match_dup 0))) ! (set (reg:SI SP_REG) ! (plus:SI (match_dup 0) ! (const_int 4)))] ! "" ! "unlk %0") ! ! (define_insn "load_got" ! [(set (match_operand:SI 0 "register_operand" "=a") ! (unspec:SI [(const_int 0)] UNSPEC_GOT))] ! "" ! { ! if (TARGET_ID_SHARED_LIBRARY) ! { ! operands[1] = gen_rtx_REG (Pmode, PIC_REG); ! return MOTOROLA ? "move.l %?(%1),%0" : "movel %1@(%?), %0"; ! } ! else if (MOTOROLA) ! { ! if (TARGET_COLDFIRE) ! /* Load the full 32-bit PC-relative offset of ! _GLOBAL_OFFSET_TABLE_ into the PIC register, then use it to ! calculate the absolute value. The offset and "lea" ! operation word together occupy 6 bytes. */ ! return ("move.l #_GLOBAL_OFFSET_TABLE_@GOTPC, %0\n\t" ! "lea (-6, %%pc, %0), %0"); ! else ! return "lea (%%pc, _GLOBAL_OFFSET_TABLE_@GOTPC), %0"; ! } ! else ! return ("movel #_GLOBAL_OFFSET_TABLE_, %0\n\t" ! "lea %%pc@(0,%0:l),%0"); }) (define_insn "indirect_jump" ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 37/63] Use RTL for prologues and epilogues 2007-01-10 11:49 ` [ColdFire 36/63] Use RTL for prologues and epilogues Richard Sandiford @ 2007-01-10 11:50 ` Richard Sandiford 2007-01-10 11:51 ` [ColdFire 38/63] Clean up handling of integer moves Richard Sandiford 2007-01-16 17:58 ` [ColdFire 37/63] Use RTL for prologues and epilogues Jeffrey Law 2007-01-10 23:06 ` [ColdFire 36/63] " Joseph S. Myers ` (2 subsequent siblings) 3 siblings, 2 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 11:50 UTC (permalink / raw) To: gcc-patches This patch is an update of: http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01366.html see there for rationale. The changes from the original patch are as follows: - It uses new predicates rather than separate HARD_FP_REG_P checks to request a particular type of register. - It avoids hard-coding (mem: ...)s into the output pattern as these MEMs will have no aliasing information. (This would become important if we added scheduling descriptions later on.) Instead, it generates new forms of the original MEMs. - It stops the peepholes from emitting an addition of 0. - The current QImode peepholes use: [(set (mem:QI (pre_dec:SI (reg:SI SP_REG))) (match_operand:QI 0 "..." "")) (set (reg:SI SP_REG) (minus:SI (reg:SI SP_REG) (const_int 2)))] but given that we're generating an SImode access, I'm sure that that 2 was meant to be a 3. The pattern should never match anyway because (minus ... (const_int ..)) isn't canonical. The patch fixes both problems. - The register form of the QImode peephole is a win on Coldfire too, so the patch continues to allow it there. Richard gcc/ 200x-xx-xx Paul Brook <paul@codesourcery.com> Richard Sandiford <richard@codesourcery.com> * config/m68k/predicates.md (integer_register): New predicate. (float_register): Likewise. * config/m68k/m68k.md (UNSPEC_MOVEQ_MEM): New constant. (*movsi_smallconst): New pattern. Convert the first define_peephole to a define_peephole2. Use float_register and integer_register than than separate REGNO checks. Convert the second and third define_peepholes to define_peephole2s. Convert the fourth define_peephole into two separate define_peephole2s, one for register sources and one for other types of source. Fix the size of the separate stack adjustment and expect it to be a PLUS of a negative constant rather than a MINUS of a positive constant. Index: gcc/config/m68k/predicates.md =================================================================== --- gcc/config/m68k/predicates.md 2007-01-09 15:02:08.000000000 +0000 +++ gcc/config/m68k/predicates.md 2007-01-09 15:02:16.000000000 +0000 @@ -181,3 +181,15 @@ (define_predicate "post_inc_operand" (define_predicate "pre_dec_operand" (and (match_code "mem") (match_test "GET_CODE (XEXP (op, 0)) == PRE_DEC"))) + +;; A hard integer register + +(define_predicate "integer_register" + (and (match_code "reg") + (match_test "INT_REGNO_P (REGNO (op))"))) + +;; A hard floating-point register + +(define_predicate "float_register" + (and (match_code "reg") + (match_test "FP_REGNO_P (REGNO (op))"))) Index: gcc/config/m68k/m68k.md =================================================================== --- gcc/config/m68k/m68k.md 2007-01-09 15:02:15.000000000 +0000 +++ gcc/config/m68k/m68k.md 2007-01-09 15:02:16.000000000 +0000 @@ -114,7 +114,8 @@ (define_constants [(UNSPEC_SIN 1) (UNSPEC_COS 2) - (UNSPEC_GOT 3) + (UNSPEC_MOVEQ_MEM 3) + (UNSPEC_GOT 4) ]) ;; UNSPEC_VOLATILE usage: @@ -685,6 +686,16 @@ (define_insn "" return output_move_simode (operands); }) +;; Move a constant suitable for moveq direct to memory. +(define_insn "*movsi_smallconst" + [(set (match_operand:SI 0 "memory_operand" "=m") + (unspec:SI [(match_operand:SI 1 "const_int_operand" "")] + UNSPEC_MOVEQ_MEM))] + "reload_completed && !TARGET_COLDFIRE" +{ + return output_move_simode (operands); +}) + (define_insn "*movsi_cf" [(set (match_operand:SI 0 "nonimmediate_operand" "=r<Q>,g,U") (match_operand:SI 1 "general_operand" "g,r<Q>,U"))] @@ -6660,131 +6671,97 @@ (define_insn "" ;; and then is moved into an FP register. ;; But it is mainly intended to test the support for these optimizations. -(define_peephole +(define_peephole2 [(set (reg:SI SP_REG) (plus:SI (reg:SI SP_REG) (const_int 4))) - (set (match_operand:DF 0 "register_operand" "=f") - (match_operand:DF 1 "register_operand" "ad"))] - "FP_REG_P (operands[0]) && ! FP_REG_P (operands[1])" -{ - rtx xoperands[2]; - xoperands[1] = gen_rtx_REG (SImode, REGNO (operands[1]) + 1); - output_asm_insn ("move%.l %1,%@", xoperands); - output_asm_insn ("move%.l %1,%-", operands); - return "fmove%.d %+,%0"; + (set (match_operand:DF 0 "float_register" "") + (match_operand:DF 1 "integer_register" ""))] + "" + [(set (mem:SI (reg:SI SP_REG)) (match_dup 2)) + (set (mem:SI (pre_dec:SI (reg:SI SP_REG))) (match_dup 3)) + (set (match_dup 0) (mem:DF (post_inc:SI (reg:SI SP_REG))))] +{ + operands[2] = simplify_gen_subreg (SImode, operands[1], DFmode, 4); + operands[3] = simplify_gen_subreg (SImode, operands[1], DFmode, 0); }) ;; Optimize a stack-adjust followed by a push of an argument. ;; This is said to happen frequently with -msoft-float ;; when there are consecutive library calls. -(define_peephole +(define_peephole2 [(set (reg:SI SP_REG) (plus:SI (reg:SI SP_REG) - (match_operand:SI 0 "const_int_operand" "n"))) - (set (match_operand:SF 1 "push_operand" "=m") - (match_operand:SF 2 "general_operand" "rmfF"))] + (match_operand:SI 0 "const_int_operand" ""))) + (set (match_operand:SF 1 "push_operand" "") + (match_operand:SF 2 "general_operand" ""))] "INTVAL (operands[0]) >= 4 - && ! reg_mentioned_p (stack_pointer_rtx, operands[2])" -{ - if (INTVAL (operands[0]) > 4) - { - rtx xoperands[2]; - xoperands[0] = stack_pointer_rtx; - xoperands[1] = GEN_INT (INTVAL (operands[0]) - 4); - if (INTVAL (xoperands[1]) <= 8) - { - if (!TARGET_COLDFIRE) - output_asm_insn ("addq%.w %1,%0", xoperands); - else - output_asm_insn ("addq%.l %1,%0", xoperands); - } - else if (TUNE_CPU32 && INTVAL (xoperands[1]) <= 16) - { - xoperands[1] = GEN_INT (INTVAL (xoperands[1]) - 8); - output_asm_insn ("addq%.w #8,%0\;addq%.w %1,%0", xoperands); - } - else if (INTVAL (xoperands[1]) <= 0x7FFF) - { - if (TUNE_68040) - output_asm_insn ("add%.w %1,%0", xoperands); - else if (MOTOROLA) - output_asm_insn ("lea (%c1,%0),%0", xoperands); - else - output_asm_insn ("lea %0@(%c1),%0", xoperands); - } - else - output_asm_insn ("add%.l %1,%0", xoperands); - } - if (FP_REG_P (operands[2])) - return "fmove%.s %2,%@"; - return "move%.l %2,%@"; + && !reg_mentioned_p (stack_pointer_rtx, operands[2])" + [(set (match_dup 3) + (match_dup 2))] +{ + if (INTVAL (operands[0]) != 4) + emit_insn (gen_add2_insn (stack_pointer_rtx, + GEN_INT (INTVAL (operands[0]) - 4))); + operands[3] = replace_equiv_address (operands[1], stack_pointer_rtx); }) ;; Speed up stack adjust followed by a fullword fixedpoint push. -(define_peephole +(define_peephole2 [(set (reg:SI SP_REG) (plus:SI (reg:SI SP_REG) - (match_operand:SI 0 "const_int_operand" "n"))) - (set (match_operand:SI 1 "push_operand" "=m") - (match_operand:SI 2 "general_operand" "g"))] + (match_operand:SI 0 "const_int_operand" ""))) + (set (match_operand:SI 1 "push_operand" "") + (match_operand:SI 2 "general_operand" ""))] "INTVAL (operands[0]) >= 4 - && ! reg_mentioned_p (stack_pointer_rtx, operands[2])" -{ - if (INTVAL (operands[0]) > 4) - { - rtx xoperands[2]; - xoperands[0] = stack_pointer_rtx; - xoperands[1] = GEN_INT (INTVAL (operands[0]) - 4); - if (INTVAL (xoperands[1]) <= 8) - { - if (!TARGET_COLDFIRE) - output_asm_insn ("addq%.w %1,%0", xoperands); - else - output_asm_insn ("addq%.l %1,%0", xoperands); - } - else if (TUNE_CPU32 && INTVAL (xoperands[1]) <= 16) - { - xoperands[1] = GEN_INT (INTVAL (xoperands[1]) - 8); - output_asm_insn ("addq%.w #8,%0\;addq%.w %1,%0", xoperands); - } - else if (INTVAL (xoperands[1]) <= 0x7FFF) - { - if (TUNE_68040) - output_asm_insn ("add%.w %1,%0", xoperands); - else if (MOTOROLA) - output_asm_insn ("lea (%c1,%0),%0", xoperands); - else - output_asm_insn ("lea %0@(%c1),%0", xoperands); - } - else - output_asm_insn ("add%.l %1,%0", xoperands); - } - if (operands[2] == const0_rtx) - return "clr%.l %@"; - return "move%.l %2,%@"; + && !reg_mentioned_p (stack_pointer_rtx, operands[2])" + [(set (match_dup 3) + (match_dup 2))] +{ + if (INTVAL (operands[0]) != 4) + emit_insn (gen_add2_insn (stack_pointer_rtx, + GEN_INT (INTVAL (operands[0]) - 4))); + operands[3] = replace_equiv_address (operands[1], stack_pointer_rtx); + + /* The 68k movsi pattern doesn't allow small constants to be moved + directly to memory. */ + if (!TARGET_COLDFIRE + && GET_CODE (operands[2]) == CONST_INT + && operands[2] != const0_rtx + && IN_RANGE (INTVAL (operands[2]), -0x80, 0x7f)) + operands[2] = gen_rtx_UNSPEC (SImode, gen_rtvec (1, operands[2]), + UNSPEC_MOVEQ_MEM); }) ;; Speed up pushing a single byte but leaving four bytes of space. -(define_peephole - [(set (mem:QI (pre_dec:SI (reg:SI SP_REG))) - (match_operand:QI 1 "general_operand" "dami")) - (set (reg:SI SP_REG) (minus:SI (reg:SI SP_REG) (const_int 2)))] - "! reg_mentioned_p (stack_pointer_rtx, operands[1])" +(define_peephole2 + [(set (match_operand:QI 0 "push_operand" "") + (match_operand:QI 1 "register_operand" "")) + (set (reg:SI SP_REG) (plus:SI (reg:SI SP_REG) (const_int -3)))] + "!reg_mentioned_p (stack_pointer_rtx, operands[1])" + [(set (match_dup 2) + (match_dup 3))] { - rtx xoperands[4]; + rtx addr; - if (GET_CODE (operands[1]) == REG) - return "move%.l %1,%-"; - - xoperands[1] = operands[1]; - xoperands[2] - = gen_rtx_MEM (QImode, plus_constant (stack_pointer_rtx, 3)); - xoperands[3] = stack_pointer_rtx; - if (!TARGET_COLDFIRE) - output_asm_insn ("subq%.w #4,%3\;move%.b %1,%2", xoperands); - else - output_asm_insn ("subq%.l #4,%3\;move%.b %1,%2", xoperands); - return ""; + addr = gen_rtx_PRE_DEC (Pmode, stack_pointer_rtx); + operands[2] = adjust_automodify_address (operands[0], SImode, addr, -3); + operands[3] = simplify_gen_subreg (SImode, operands[1], QImode, 0); +}) + +(define_peephole2 + [(set (match_operand:QI 0 "push_operand" "") + (match_operand:QI 1 "general_operand" "")) + (set (reg:SI SP_REG) (plus:SI (reg:SI SP_REG) (const_int -3)))] + ;; Disabled for coldfire because it isn't a size win. + "!TARGET_COLDFIRE + && !register_operand (operands[1], VOIDmode) + && !reg_mentioned_p (stack_pointer_rtx, operands[1])" + [(set (reg:SI SP_REG) (plus:SI (reg:SI SP_REG) (const_int -4))) + (set (match_dup 2) + (match_dup 1))] +{ + operands[2] = replace_equiv_address (operands[0], + plus_constant (stack_pointer_rtx, 3)); }) (define_peephole ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 38/63] Clean up handling of integer moves 2007-01-10 11:50 ` [ColdFire 37/63] " Richard Sandiford @ 2007-01-10 11:51 ` Richard Sandiford 2007-01-10 11:53 ` [ColdFire 39/63] Fix mov3q handling Richard Sandiford 2007-01-16 17:49 ` [ColdFire 38/63] Clean up handling of integer moves Jeffrey Law 2007-01-16 17:58 ` [ColdFire 37/63] Use RTL for prologues and epilogues Jeffrey Law 1 sibling, 2 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 11:51 UTC (permalink / raw) To: gcc-patches This patch makes various constant-related functions take a HOST_WIDE_INT rather than a CONST_INT rtx. It's partly a cleanup, but the valid_mov3q_const part is also needed by the next patch. Richard gcc/ * config/m68k/m68k-protos.h (valid_mov3q_const): Take a HOST_WIDE_INT and return a bool. (output_move_const_into_data_reg, output_move_simode_const): Delete. * config/m68k/m68k.c (const_method, const_int_cost): Take a HOST_WIDE_INT instead of an rtx. (m68k_rtx_costs): Update call accordingly. (output_move_const_into_data_reg): Likewise. Fix formatting. (valid_mov3q_const): Take a HOST_WIDE_INT instead of an rtx. Return a bool. (output_move_simode_const): Update calls after above changes. Rework to use automatic variables and predicates like MEM_P. * config/m68k/m68k.md (pushexthisi_const): Update call to valid_mov3q_const. Index: gcc/config/m68k/m68k-protos.h =================================================================== --- gcc/config/m68k/m68k-protos.h 2007-01-09 15:02:15.000000000 +0000 +++ gcc/config/m68k/m68k-protos.h 2007-01-09 15:02:16.000000000 +0000 @@ -23,9 +23,7 @@ the Free Software Foundation; either ver #ifdef RTX_CODE extern bool m68k_interrupt_function_p (tree); extern HOST_WIDE_INT m68k_initial_elimination_offset (int from, int to); -extern const char *output_move_const_into_data_reg (rtx *); -extern int valid_mov3q_const (rtx); -extern const char *output_move_simode_const (rtx *); +extern bool valid_mov3q_const (HOST_WIDE_INT); extern const char *output_move_simode (rtx *); extern const char *output_move_himode (rtx *); extern const char *output_move_qimode (rtx *); Index: gcc/config/m68k/m68k.c =================================================================== --- gcc/config/m68k/m68k.c 2007-01-09 15:02:15.000000000 +0000 +++ gcc/config/m68k/m68k.c 2007-01-09 15:02:16.000000000 +0000 @@ -146,7 +146,6 @@ static tree m68k_handle_fndecl_attribute bool *no_add_attrs); static void m68k_compute_frame_layout (void); static bool m68k_save_reg (unsigned int regno, bool interrupt_handler); -static int const_int_cost (rtx); static bool m68k_rtx_costs (rtx, int, int, int *); \f @@ -1943,17 +1942,15 @@ legitimize_pic_address (rtx orig, enum m \f typedef enum { MOVL, SWAP, NEGW, NOTW, NOTB, MOVQ, MVS, MVZ } CONST_METHOD; -static CONST_METHOD const_method (rtx); - #define USE_MOVQ(i) ((unsigned) ((i) + 128) <= 255) +/* Return the type of move that should be used for integer I. */ + static CONST_METHOD -const_method (rtx constant) +const_method (HOST_WIDE_INT i) { - int i; unsigned u; - i = INTVAL (constant); if (USE_MOVQ (i)) return MOVQ; @@ -1991,10 +1988,12 @@ const_method (rtx constant) return MOVL; } +/* Return the cost of moving constant I into a data register. */ + static int -const_int_cost (rtx constant) +const_int_cost (HOST_WIDE_INT i) { - switch (const_method (constant)) + switch (const_method (i)) { case MOVQ: /* Constants between -128 and 127 are cheap due to moveq. */ @@ -2024,7 +2023,7 @@ m68k_rtx_costs (rtx x, int code, int out if (x == const0_rtx) *total = 0; else - *total = const_int_cost (x); + *total = const_int_cost (INTVAL (x)); return true; case CONST: @@ -2149,13 +2148,16 @@ #define DIVW_COST \ } } -const char * +/* Return an instruction to move CONST_INT OPERANDS[1] into data regsiter + OPERANDS[0]. */ + +static const char * output_move_const_into_data_reg (rtx *operands) { - int i; + HOST_WIDE_INT i; i = INTVAL (operands[1]); - switch (const_method (operands[1])) + switch (const_method (i)) { case MVZ: return "mvzw %1,%0"; @@ -2182,63 +2184,55 @@ output_move_const_into_data_reg (rtx *op return "moveq %1,%0\n\tswap %0"; } case MOVL: - return "move%.l %1,%0"; + return "move%.l %1,%0"; default: - gcc_unreachable (); + gcc_unreachable (); } } -/* Return 1 if 'constant' can be represented by - mov3q on a ColdFire V4 core. */ -int -valid_mov3q_const (rtx constant) -{ - int i; +/* Return true if I can be handled by ISA B's mov3q instruction. */ - if (TARGET_ISAB && GET_CODE (constant) == CONST_INT) - { - i = INTVAL (constant); - if (i == -1 || (i >= 1 && i <= 7)) - return 1; - } - return 0; +bool +valid_mov3q_const (HOST_WIDE_INT i) +{ + return TARGET_ISAB && (i == -1 || IN_RANGE (i, 1, 7)); } +/* Return an instruction to move CONST_INT OPERANDS[1] into OPERANDS[0]. + I is the value of OPERANDS[1]. */ -const char * +static const char * output_move_simode_const (rtx *operands) { - if (operands[1] == const0_rtx - && (DATA_REG_P (operands[0]) - || GET_CODE (operands[0]) == MEM) + rtx dest; + HOST_WIDE_INT src; + + dest = operands[0]; + src = INTVAL (operands[1]); + if (src == 0 + && (DATA_REG_P (dest) || MEM_P (dest)) /* clr insns on 68000 read before writing. */ && ((TARGET_68010 || TARGET_COLDFIRE) - || !(GET_CODE (operands[0]) == MEM - && MEM_VOLATILE_P (operands[0])))) + || !(MEM_P (dest) && MEM_VOLATILE_P (dest)))) return "clr%.l %0"; - else if ((GET_MODE (operands[0]) == SImode) - && valid_mov3q_const (operands[1])) + else if (GET_MODE (dest) == SImode && valid_mov3q_const (src)) return "mov3q%.l %1,%0"; - else if (operands[1] == const0_rtx - && ADDRESS_REG_P (operands[0])) + else if (src == 0 && ADDRESS_REG_P (dest)) return "sub%.l %0,%0"; - else if (DATA_REG_P (operands[0])) + else if (DATA_REG_P (dest)) return output_move_const_into_data_reg (operands); - else if (ADDRESS_REG_P (operands[0]) - && INTVAL (operands[1]) < 0x8000 - && INTVAL (operands[1]) >= -0x8000) + else if (ADDRESS_REG_P (dest) && IN_RANGE (src, -0x8000, 0x7fff)) { - if (valid_mov3q_const (operands[1])) + if (valid_mov3q_const (src)) return "mov3q%.l %1,%0"; return "move%.w %1,%0"; } - else if (GET_CODE (operands[0]) == MEM - && GET_CODE (XEXP (operands[0], 0)) == PRE_DEC - && REGNO (XEXP (XEXP (operands[0], 0), 0)) == STACK_POINTER_REGNUM - && INTVAL (operands[1]) < 0x8000 - && INTVAL (operands[1]) >= -0x8000) + else if (MEM_P (dest) + && GET_CODE (XEXP (dest, 0)) == PRE_DEC + && REGNO (XEXP (XEXP (dest, 0), 0)) == STACK_POINTER_REGNUM + && IN_RANGE (src, -0x8000, 0x7fff)) { - if (valid_mov3q_const (operands[1])) + if (valid_mov3q_const (src)) return "mov3q%.l %1,%-"; return "pea %a1"; } Index: gcc/config/m68k/m68k.md =================================================================== --- gcc/config/m68k/m68k.md 2007-01-09 15:02:16.000000000 +0000 +++ gcc/config/m68k/m68k.md 2007-01-09 15:02:16.000000000 +0000 @@ -584,7 +584,7 @@ (define_insn "pushexthisi_const" { if (operands[1] == const0_rtx) return "clr%.l %0"; - if (valid_mov3q_const(operands[1])) + if (valid_mov3q_const (INTVAL (operands[1]))) return "mov3q%.l %1,%-"; return "pea %a1"; }) ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 39/63] Fix mov3q handling 2007-01-10 11:51 ` [ColdFire 38/63] Clean up handling of integer moves Richard Sandiford @ 2007-01-10 11:53 ` Richard Sandiford 2007-01-10 11:55 ` [ColdFire 40/63] Add more movsf_cf_soft alternatives Richard Sandiford 2007-01-10 18:46 ` [ColdFire 39/63] Fix mov3q handling Jeffrey Law 2007-01-16 17:49 ` [ColdFire 38/63] Clean up handling of integer moves Jeffrey Law 1 sibling, 2 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 11:53 UTC (permalink / raw) To: gcc-patches m68k.md has a separate *movsi_cfv4 pattern that differs *movsi_cf only in the addition of 'R' constraints. It seems fairly obvious from context that 'R' was supposed to be a mov3q constant, but nothing actually defines it. This patch maps 'R' to valid_mov3q_const. Because valid_mov3q_const checks the architecture itself, there's no need for a separate pattern; we can use the *movsi_cfv4 form for other ColdFire targets too. Also, the 'R' in the first *movsi_cfv4 alternative is redundant, as 'R' implies 'g'. Richard gcc/ 200x-xx-xx Richard Sandiford <richard@codesourcery.com> Julian Brown <julian@codesourcery.com> * config/m68k/m68k.h (CONST_OK_FOR_LETTER_P): Add an 'R' case. * config/m68k/m68k.md (*movsi_cfv4): Fold into... (*movsi_cf): ...here. Remove unnecessary 'R' from 'Rg'. Add commentary. Index: gcc/config/m68k/m68k.h =================================================================== --- gcc/config/m68k/m68k.h 2007-01-09 15:02:15.000000000 +0000 +++ gcc/config/m68k/m68k.h 2007-01-09 15:02:17.000000000 +0000 @@ -494,7 +494,8 @@ #define REG_CLASS_FROM_LETTER(C) \ `M' is for numbers that moveq+notb can't handle. 'N' is for range 24 to 31, rotatert:SI 8 to 1 expressed as rotate. 'O' is for 16 (for rotate using swap). - 'P' is for range 8 to 15, rotatert:HI 8 to 1 expressed as rotate. */ + 'P' is for range 8 to 15, rotatert:HI 8 to 1 expressed as rotate. + 'R' is for numbers that mov3q can handle. */ #define CONST_OK_FOR_LETTER_P(VALUE, C) \ ((C) == 'I' ? (VALUE) > 0 && (VALUE) <= 8 : \ (C) == 'J' ? (VALUE) >= -0x8000 && (VALUE) <= 0x7FFF : \ @@ -503,7 +504,8 @@ #define CONST_OK_FOR_LETTER_P(VALUE, C) (C) == 'M' ? (VALUE) < -0x100 || (VALUE) >= 0x100 : \ (C) == 'N' ? (VALUE) >= 24 && (VALUE) <= 31 : \ (C) == 'O' ? (VALUE) == 16 : \ - (C) == 'P' ? (VALUE) >= 8 && (VALUE) <= 15 : 0) + (C) == 'P' ? (VALUE) >= 8 && (VALUE) <= 15 : \ + (C) == 'R' ? valid_mov3q_const (VALUE) : 0) /* "G" defines all of the floating constants that are *NOT* 68881 constants. This is so 68881 constants get reloaded and the Index: gcc/config/m68k/m68k.md =================================================================== --- gcc/config/m68k/m68k.md 2007-01-09 15:02:16.000000000 +0000 +++ gcc/config/m68k/m68k.md 2007-01-09 15:02:17.000000000 +0000 @@ -696,16 +696,11 @@ (define_insn "*movsi_smallconst" return output_move_simode (operands); }) +;; ColdFire move instructions can have at most one operand of mode >= 6. (define_insn "*movsi_cf" [(set (match_operand:SI 0 "nonimmediate_operand" "=r<Q>,g,U") - (match_operand:SI 1 "general_operand" "g,r<Q>,U"))] - "TARGET_COLDFIRE && !TARGET_ISAB" - "* return output_move_simode (operands);") - -(define_insn "*movsi_cfv4" - [(set (match_operand:SI 0 "nonimmediate_operand" "=r<Q>,g,U") - (match_operand:SI 1 "general_operand" "Rg,Rr<Q>,U"))] - "TARGET_ISAB" + (match_operand:SI 1 "general_operand" "g,Rr<Q>,U"))] + "TARGET_COLDFIRE" "* return output_move_simode (operands);") ;; Special case of fullword move, where we need to get a non-GOT PIC ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 40/63] Add more movsf_cf_soft alternatives 2007-01-10 11:53 ` [ColdFire 39/63] Fix mov3q handling Richard Sandiford @ 2007-01-10 11:55 ` Richard Sandiford 2007-01-10 11:55 ` [ColdFire 41/63] Add support for the ff1 instruction Richard Sandiford 2007-01-10 18:46 ` [ColdFire 40/63] Add more movsf_cf_soft alternatives Jeffrey Law 2007-01-10 18:46 ` [ColdFire 39/63] Fix mov3q handling Jeffrey Law 1 sibling, 2 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 11:55 UTC (permalink / raw) To: gcc-patches The movsf_cf_soft constraints reject some operand combinations that are supported by the underlying instructions. This patch fixes that. The post-patch constraints are the same as those in the equivalent SImode patterns, minus the use of mov3q constants. Richard gcc/ * config/m68k/m68k.md (movsf_cf_soft): Provide the same non-mov3q alternatives as movsi_cf. (movsf_cf_hard): Add commentary. Index: gcc/config/m68k/m68k.md =================================================================== --- gcc/config/m68k/m68k.md 2007-01-09 15:02:17.000000000 +0000 +++ gcc/config/m68k/m68k.md 2007-01-09 15:02:18.000000000 +0000 @@ -871,13 +871,15 @@ (define_insn "" }) (define_insn "movsf_cf_soft" - [(set (match_operand:SF 0 "nonimmediate_operand" "=r,g") - (match_operand:SF 1 "general_operand" "g,r"))] + [(set (match_operand:SF 0 "nonimmediate_operand" "=r<Q>,g,U") + (match_operand:SF 1 "general_operand" "g,r<Q>,U"))] "TARGET_COLDFIRE && !TARGET_COLDFIRE_FPU" { return "move%.l %1,%0"; }) +;; SFmode MEMs are restricted to modes 2-4 if TARGET_COLDFIRE_FPU. +;; The move instructions can handle all combinations. (define_insn "movsf_cf_hard" [(set (match_operand:SF 0 "nonimmediate_operand" "=rm,f, f,rm,f,r<Q>,f,m") (match_operand:SF 1 "general_operand" " f, rm,f,rm,F,F, m,f"))] ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 41/63] Add support for the ff1 instruction 2007-01-10 11:55 ` [ColdFire 40/63] Add more movsf_cf_soft alternatives Richard Sandiford @ 2007-01-10 11:55 ` Richard Sandiford 2007-01-10 11:56 ` [ColdFire 42/63] Add support for sibling calls Richard Sandiford 2007-01-10 19:21 ` [ColdFire 41/63] Add support for the ff1 instruction Jeffrey Law 2007-01-10 18:46 ` [ColdFire 40/63] Add more movsf_cf_soft alternatives Jeffrey Law 1 sibling, 2 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 11:55 UTC (permalink / raw) To: gcc-patches This patch adds support for the ISA A+ and ISA C ff1 instruction. Richard gcc/ 200x-xx-xx Sandra Loosemore <sandra@codesourcery.com> * longlong.h (count_leading_zeros, COUNT_LEADING_ZEROS_0): Add ColdFire alternatives. * config/m68k/m68k.h (CLZ_DEFINED_VALUE_AT_ZERO): New macro. * config/m68k/m68k.md (clzsi2): Define for ColdFire architectures that support ff1 instruction. Index: gcc/longlong.h =================================================================== --- gcc/longlong.h 2007-01-09 13:18:11.000000000 +0000 +++ gcc/longlong.h 2007-01-09 15:02:18.000000000 +0000 @@ -521,6 +521,11 @@ #define count_leading_zeros(count, x) \ __asm__ ("bfffo %1{%b2:%b2},%0" \ : "=d" ((USItype) (count)) \ : "od" ((USItype) (x)), "n" (0)) +/* Some ColdFire architectures have a ff1 instruction supported via + __builtin_clz. */ +#elif defined (__mcfisaaplus__) || defined (__mcfisac__) +#define count_leading_zeros(count,x) ((count) = __builtin_clz (x)) +#define COUNT_LEADING_ZEROS_0 32 #endif #endif /* mc68000 */ Index: gcc/config/m68k/m68k.h =================================================================== --- gcc/config/m68k/m68k.h 2007-01-09 15:02:17.000000000 +0000 +++ gcc/config/m68k/m68k.h 2007-01-09 15:02:18.000000000 +0000 @@ -894,6 +894,9 @@ #define SLOW_BYTE_ACCESS 0 #define TRULY_NOOP_TRUNCATION(OUTPREC, INPREC) 1 +/* The ColdFire FF1 instruction returns 32 for zero. */ +#define CLZ_DEFINED_VALUE_AT_ZERO(MODE, VALUE) ((VALUE) = 32, 1) + #define STORE_FLAG_VALUE (-1) #define Pmode SImode Index: gcc/config/m68k/m68k.md =================================================================== --- gcc/config/m68k/m68k.md 2007-01-09 15:02:18.000000000 +0000 +++ gcc/config/m68k/m68k.md 2007-01-09 15:02:18.000000000 +0000 @@ -3990,6 +3990,15 @@ (define_insn "abs<mode>2_cf" return "f<FP:prec>abs%.<FP:prec> %1,%0"; }) \f +;; bit indexing instructions + +;; ColdFire ff1 instruction implements clz. +(define_insn "clzsi2" + [(set (match_operand:SI 0 "register_operand" "=d") + (clz:SI (match_operand:SI 1 "register_operand" "0")))] + "TARGET_ISAAPLUS || TARGET_ISAC" + "ff1 %0") +\f ;; one complement instructions ;; "one_cmpldi2" is mainly here to help combine(). ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 42/63] Add support for sibling calls 2007-01-10 11:55 ` [ColdFire 41/63] Add support for the ff1 instruction Richard Sandiford @ 2007-01-10 11:56 ` Richard Sandiford 2007-01-10 11:57 ` [ColdFire 43/63] Use floating-point branches on ColdFire too Richard Sandiford 2007-01-16 18:04 ` [ColdFire 42/63] Add support for sibling calls Jeffrey Law 2007-01-10 19:21 ` [ColdFire 41/63] Add support for the ff1 instruction Jeffrey Law 1 sibling, 2 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 11:56 UTC (permalink / raw) To: gcc-patches This patch adds support for sibcalls. It's a useful optimisation in its own right, but it's also needed by the upcoming thunks patch. Indirect sibcalls must use a register that isn't clobbered by the epilogue, and that isn't live on entry to the callee. The patch uses the static chain register for this purpose and forbids sibcalls to functions that need a static chain register. The sibcall_operand predicate only allows valid constants and the static chain register. The operand therefore doesn't need to be (and shouldn't be) reloaded, so the patch uses empty constraints. This seems better than adding a special register class. Richard gcc/ * config/m68k/m68k-protos.h (output_sibcall): Declare. (mips_expand_epilogue): Add a bool parameter. (m68k_legitimize_sibcall_address): Declare. * config/m68k/m68k.c (TARGET_FUNCTION_OK_FOR_SIBCALL): Define. (m68k_expand_epilogue): Add a parameter to select between sibling and normal epilogues. Only generate a return for the latter. (m68k_ok_for_sibcall_p): New function. (m68k_legitimize_sibcall_address, output_sibcall): New functions. * config/m68k/m68k.md (sibcall, *sibcall): New patterns. (sibcall_value, *sibcall_value): Likewise. (*call, *call_value): Require !SIBLING_CALL_P. (epilogue): Update call to m68k_expand_epilogue. (sibcall_epilogue): New pattern. * config/m68k/predicates.md (const_call_operand): Say that this predicate applies to sibling calls too. (sibcall_operand): New predicate. Index: gcc/config/m68k/m68k-protos.h =================================================================== --- gcc/config/m68k/m68k-protos.h 2007-01-09 15:02:16.000000000 +0000 +++ gcc/config/m68k/m68k-protos.h 2007-01-09 15:02:19.000000000 +0000 @@ -39,6 +39,7 @@ extern const char *output_andsi3 (rtx *) extern const char *output_iorsi3 (rtx *); extern const char *output_xorsi3 (rtx *); extern const char *output_call (rtx); +extern const char *output_sibcall (rtx); extern void output_dbcc_and_branch (rtx *); extern int floating_exact_log2 (rtx); extern bool strict_low_part_peephole_ok (enum machine_mode mode, rtx first_insn, rtx target); @@ -68,10 +69,11 @@ extern bool m68k_regno_mode_ok (int, enu extern int flags_in_68881 (void); extern void m68k_expand_prologue (void); extern bool m68k_use_return_insn (void); -extern void m68k_expand_epilogue (void); +extern void m68k_expand_epilogue (bool); extern void override_options (void); extern const char *m68k_cpp_cpu_ident (const char *); extern const char *m68k_cpp_cpu_family (const char *); extern void init_68881_table (void); extern rtx m68k_legitimize_call_address (rtx); +extern rtx m68k_legitimize_sibcall_address (rtx); extern int m68k_hard_regno_rename_ok(unsigned int, unsigned int); Index: gcc/config/m68k/m68k.c =================================================================== --- gcc/config/m68k/m68k.c 2007-01-09 15:02:16.000000000 +0000 +++ gcc/config/m68k/m68k.c 2007-01-09 15:02:19.000000000 +0000 @@ -146,6 +146,7 @@ static tree m68k_handle_fndecl_attribute bool *no_add_attrs); static void m68k_compute_frame_layout (void); static bool m68k_save_reg (unsigned int regno, bool interrupt_handler); +static bool m68k_ok_for_sibcall_p (tree, tree); static bool m68k_rtx_costs (rtx, int, int, int *); \f @@ -215,6 +216,9 @@ #define TARGET_STRUCT_VALUE_RTX m68k_str #undef TARGET_CANNOT_FORCE_CONST_MEM #define TARGET_CANNOT_FORCE_CONST_MEM m68k_illegitimate_symbolic_constant_p +#undef TARGET_FUNCTION_OK_FOR_SIBCALL +#define TARGET_FUNCTION_OK_FOR_SIBCALL m68k_ok_for_sibcall_p + static const struct attribute_spec m68k_attribute_table[] = { /* { name, min_len, max_len, decl_req, type_req, fn_type_req, handler } */ @@ -1015,7 +1019,8 @@ m68k_use_return_insn (void) return current_frame.offset == 0; } -/* Emit RTL for the "epilogue" define_expand. +/* Emit RTL for the "epilogue" or "sibcall_epilogue" define_expand; + SIBCALL_P says which. The function epilogue should not depend on the current stack pointer! It should use the frame pointer only, if there is a frame pointer. @@ -1023,7 +1028,7 @@ m68k_use_return_insn (void) omit stack adjustments before returning. */ void -m68k_expand_epilogue (void) +m68k_expand_epilogue (bool sibcall_p) { HOST_WIDE_INT fsize, fsize_with_regs; bool big, restore_from_sp; @@ -1181,7 +1186,8 @@ m68k_expand_epilogue (void) stack_pointer_rtx, EH_RETURN_STACKADJ_RTX)); - emit_insn (gen_rtx_RETURN (VOIDmode)); + if (!sibcall_p) + emit_insn (gen_rtx_RETURN (VOIDmode)); } \f /* Return true if X is a valid comparison operator for the dbcc @@ -1218,6 +1224,16 @@ flags_in_68881 (void) return cc_status.flags & CC_IN_68881; } +/* Implement TARGET_FUNCTION_OK_FOR_SIBCALL_P. We cannot use sibcalls + for nested functions because we use the static chain register for + indirect calls. */ + +static bool +m68k_ok_for_sibcall_p (tree decl ATTRIBUTE_UNUSED, tree exp) +{ + return TREE_OPERAND (exp, 2) == NULL; +} + /* Convert X to a legitimate function call memory reference and return the result. */ @@ -1230,6 +1246,19 @@ m68k_legitimize_call_address (rtx x) return replace_equiv_address (x, force_reg (Pmode, XEXP (x, 0))); } +/* Likewise for sibling calls. */ + +rtx +m68k_legitimize_sibcall_address (rtx x) +{ + gcc_assert (MEM_P (x)); + if (sibcall_operand (XEXP (x, 0), VOIDmode)) + return x; + + emit_move_insn (gen_rtx_REG (Pmode, STATIC_CHAIN_REGNUM), XEXP (x, 0)); + return replace_equiv_address (x, gen_rtx_REG (Pmode, STATIC_CHAIN_REGNUM)); +} + /* Output a dbCC; jCC sequence. Note we do not handle the floating point version of this sequence (Fdbcc). We also do not handle alternative conditions when CC_NO_OVERFLOW is @@ -3978,6 +4007,17 @@ output_call (rtx x) return "jsr %a0"; } +/* Likewise sibling calls. */ + +const char * +output_sibcall (rtx x) +{ + if (symbolic_operand (x, VOIDmode)) + return m68k_symbolic_jump; + else + return "jmp %a0"; +} + #ifdef M68K_TARGET_COFF /* Output assembly to switch to section NAME with attribute FLAGS. */ Index: gcc/config/m68k/m68k.md =================================================================== --- gcc/config/m68k/m68k.md 2007-01-09 15:02:18.000000000 +0000 +++ gcc/config/m68k/m68k.md 2007-01-09 15:02:19.000000000 +0000 @@ -6403,6 +6403,41 @@ (define_insn "" "subql #1,%0\;cmpl #-1,%0\;jne %l1"; }) +(define_expand "sibcall" + [(call (match_operand:QI 0 "memory_operand" "") + (match_operand:SI 1 "general_operand" ""))] + "" +{ + operands[0] = m68k_legitimize_sibcall_address (operands[0]); +}) + +(define_insn "*sibcall" + [(call (mem:QI (match_operand:SI 0 "sibcall_operand" "")) + (match_operand:SI 1 "general_operand" ""))] + "SIBLING_CALL_P (insn)" +{ + return output_sibcall (operands[0]); +}) + +(define_expand "sibcall_value" + [(set (match_operand 0 "" "") + (call (match_operand:QI 1 "memory_operand" "") + (match_operand:SI 2 "general_operand" "")))] + "" +{ + operands[1] = m68k_legitimize_sibcall_address (operands[1]); +}) + +(define_insn "*sibcall_value" + [(set (match_operand 0 "" "=rf,rf") + (call (mem:QI (match_operand:SI 1 "sibcall_operand" "")) + (match_operand:SI 2 "general_operand" "")))] + "SIBLING_CALL_P (insn)" +{ + operands[0] = operands[1]; + return output_sibcall (operands[0]); +}) + ;; Call subroutine with no return value. (define_expand "call" [(call (match_operand:QI 0 "memory_operand" "") @@ -6417,7 +6452,7 @@ (define_insn "*call" [(call (mem:QI (match_operand:SI 0 "call_operand" "a,W")) (match_operand:SI 1 "general_operand" "g,g"))] ;; Operand 1 not really used on the m68000. - "" + "!SIBLING_CALL_P (insn)" { return output_call (operands[0]); }) @@ -6439,7 +6474,7 @@ (define_insn "*call_value" (call (mem:QI (match_operand:SI 1 "call_operand" "a,W")) (match_operand:SI 2 "general_operand" "g,g")))] ;; Operand 2 not really used on the m68000. - "" + "!SIBLING_CALL_P (insn)" { operands[0] = operands[1]; return output_call (operands[0]); @@ -6498,7 +6533,15 @@ (define_expand "epilogue" [(return)] "" { - m68k_expand_epilogue (); + m68k_expand_epilogue (false); + DONE; +}) + +(define_expand "sibcall_epilogue" + [(return)] + "" +{ + m68k_expand_epilogue (true); DONE; }) Index: gcc/config/m68k/predicates.md =================================================================== --- gcc/config/m68k/predicates.md 2007-01-09 15:02:16.000000000 +0000 +++ gcc/config/m68k/predicates.md 2007-01-09 15:02:19.000000000 +0000 @@ -159,7 +159,7 @@ (define_predicate "symbolic_operand" } }) -;; A constant that can be used the address in a call insn. +;; A constant that can be used the address in a call or sibcall insn. (define_predicate "const_call_operand" (ior (match_operand 0 "const_int_operand") (and (match_test "m68k_symbolic_call != NULL") @@ -170,6 +170,12 @@ (define_predicate "call_operand" (ior (match_operand 0 "const_call_operand") (match_operand 0 "register_operand"))) +;; An operand that can be used as the address in a sibcall insn. +(define_predicate "sibcall_operand" + (ior (match_operand 0 "const_call_operand") + (and (match_code "reg") + (match_test "REGNO (op) == STATIC_CHAIN_REGNUM")))) + ;; TODO: Add a comment here. (define_predicate "post_inc_operand" ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 43/63] Use floating-point branches on ColdFire too 2007-01-10 11:56 ` [ColdFire 42/63] Add support for sibling calls Richard Sandiford @ 2007-01-10 11:57 ` Richard Sandiford 2007-01-10 11:58 ` [ColdFire 44/63] Remove unncessary saves and restores of %a5 Richard Sandiford 2007-01-10 17:58 ` [ColdFire 43/63] Use floating-point branches on ColdFire too Jeffrey Law 2007-01-16 18:04 ` [ColdFire 42/63] Add support for sibling calls Jeffrey Law 1 sibling, 2 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 11:57 UTC (permalink / raw) To: gcc-patches The 68881 FPU branches apply equally well to the ColdFire FPU, so this patch changes the condition from TARGET_68881 to TARGET_HARD_FLOAT. Richard gcc/ * config/m68k/m68k.md (bordered, bunordered, buneq, bunge, bungt) (bunle, bunlt, bltgt, bordered_rev, bunordered_rev, buneq_rev) (bunge_rev, bungt_rev, bunle_rev, bunlt_rev, bltgt_rev): Change condition from TARGET_68881 to TARGET_HARD_FLOAT. Index: gcc/config/m68k/m68k.md =================================================================== --- gcc/config/m68k/m68k.md 2007-01-09 15:02:19.000000000 +0000 +++ gcc/config/m68k/m68k.md 2007-01-09 15:02:20.000000000 +0000 @@ -5929,7 +5929,7 @@ (define_insn "bordered" (if_then_else (ordered (cc0) (const_int 0)) (label_ref (match_operand 0 "" "")) (pc)))] - "TARGET_68881" + "TARGET_HARD_FLOAT" { gcc_assert (cc_prev_status.flags & CC_IN_68881); return MOTOROLA ? "fbor %l0" : "fjor %l0"; @@ -5940,7 +5940,7 @@ (define_insn "bunordered" (if_then_else (unordered (cc0) (const_int 0)) (label_ref (match_operand 0 "" "")) (pc)))] - "TARGET_68881" + "TARGET_HARD_FLOAT" { gcc_assert (cc_prev_status.flags & CC_IN_68881); return MOTOROLA ? "fbun %l0" : "fjun %l0"; @@ -5951,7 +5951,7 @@ (define_insn "buneq" (if_then_else (uneq (cc0) (const_int 0)) (label_ref (match_operand 0 "" "")) (pc)))] - "TARGET_68881" + "TARGET_HARD_FLOAT" { gcc_assert (cc_prev_status.flags & CC_IN_68881); return MOTOROLA ? "fbueq %l0" : "fjueq %l0"; @@ -5962,7 +5962,7 @@ (define_insn "bunge" (if_then_else (unge (cc0) (const_int 0)) (label_ref (match_operand 0 "" "")) (pc)))] - "TARGET_68881" + "TARGET_HARD_FLOAT" { gcc_assert (cc_prev_status.flags & CC_IN_68881); return MOTOROLA ? "fbuge %l0" : "fjuge %l0"; @@ -5973,7 +5973,7 @@ (define_insn "bungt" (if_then_else (ungt (cc0) (const_int 0)) (label_ref (match_operand 0 "" "")) (pc)))] - "TARGET_68881" + "TARGET_HARD_FLOAT" { gcc_assert (cc_prev_status.flags & CC_IN_68881); return MOTOROLA ? "fbugt %l0" : "fjugt %l0"; @@ -5984,7 +5984,7 @@ (define_insn "bunle" (if_then_else (unle (cc0) (const_int 0)) (label_ref (match_operand 0 "" "")) (pc)))] - "TARGET_68881" + "TARGET_HARD_FLOAT" { gcc_assert (cc_prev_status.flags & CC_IN_68881); return MOTOROLA ? "fbule %l0" : "fjule %l0"; @@ -5995,7 +5995,7 @@ (define_insn "bunlt" (if_then_else (unlt (cc0) (const_int 0)) (label_ref (match_operand 0 "" "")) (pc)))] - "TARGET_68881" + "TARGET_HARD_FLOAT" { gcc_assert (cc_prev_status.flags & CC_IN_68881); return MOTOROLA ? "fbult %l0" : "fjult %l0"; @@ -6006,7 +6006,7 @@ (define_insn "bltgt" (if_then_else (ltgt (cc0) (const_int 0)) (label_ref (match_operand 0 "" "")) (pc)))] - "TARGET_68881" + "TARGET_HARD_FLOAT" { gcc_assert (cc_prev_status.flags & CC_IN_68881); return MOTOROLA ? "fbogl %l0" : "fjogl %l0"; @@ -6147,7 +6147,7 @@ (define_insn "*bordered_rev" (if_then_else (ordered (cc0) (const_int 0)) (pc) (label_ref (match_operand 0 "" ""))))] - "TARGET_68881" + "TARGET_HARD_FLOAT" { gcc_assert (cc_prev_status.flags & CC_IN_68881); return MOTOROLA ? "fbun %l0" : "fjun %l0"; @@ -6158,7 +6158,7 @@ (define_insn "*bunordered_rev" (if_then_else (unordered (cc0) (const_int 0)) (pc) (label_ref (match_operand 0 "" ""))))] - "TARGET_68881" + "TARGET_HARD_FLOAT" { gcc_assert (cc_prev_status.flags & CC_IN_68881); return MOTOROLA ? "fbor %l0" : "fjor %l0"; @@ -6169,7 +6169,7 @@ (define_insn "*buneq_rev" (if_then_else (uneq (cc0) (const_int 0)) (pc) (label_ref (match_operand 0 "" ""))))] - "TARGET_68881" + "TARGET_HARD_FLOAT" { gcc_assert (cc_prev_status.flags & CC_IN_68881); return MOTOROLA ? "fbogl %l0" : "fjogl %l0"; @@ -6180,7 +6180,7 @@ (define_insn "*bunge_rev" (if_then_else (unge (cc0) (const_int 0)) (pc) (label_ref (match_operand 0 "" ""))))] - "TARGET_68881" + "TARGET_HARD_FLOAT" { gcc_assert (cc_prev_status.flags & CC_IN_68881); return MOTOROLA ? "fbolt %l0" : "fjolt %l0"; @@ -6191,7 +6191,7 @@ (define_insn "*bungt_rev" (if_then_else (ungt (cc0) (const_int 0)) (pc) (label_ref (match_operand 0 "" ""))))] - "TARGET_68881" + "TARGET_HARD_FLOAT" { gcc_assert (cc_prev_status.flags & CC_IN_68881); return MOTOROLA ? "fbole %l0" : "fjole %l0"; @@ -6202,7 +6202,7 @@ (define_insn "*bunle_rev" (if_then_else (unle (cc0) (const_int 0)) (pc) (label_ref (match_operand 0 "" ""))))] - "TARGET_68881" + "TARGET_HARD_FLOAT" { gcc_assert (cc_prev_status.flags & CC_IN_68881); return MOTOROLA ? "fbogt %l0" : "fjogt %l0"; @@ -6213,7 +6213,7 @@ (define_insn "*bunlt_rev" (if_then_else (unlt (cc0) (const_int 0)) (pc) (label_ref (match_operand 0 "" ""))))] - "TARGET_68881" + "TARGET_HARD_FLOAT" { gcc_assert (cc_prev_status.flags & CC_IN_68881); return MOTOROLA ? "fboge %l0" : "fjoge %l0"; @@ -6224,7 +6224,7 @@ (define_insn "*bltgt_rev" (if_then_else (ltgt (cc0) (const_int 0)) (pc) (label_ref (match_operand 0 "" ""))))] - "TARGET_68881" + "TARGET_HARD_FLOAT" { gcc_assert (cc_prev_status.flags & CC_IN_68881); return MOTOROLA ? "fbueq %l0" : "fjueq %l0"; ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 44/63] Remove unncessary saves and restores of %a5 2007-01-10 11:57 ` [ColdFire 43/63] Use floating-point branches on ColdFire too Richard Sandiford @ 2007-01-10 11:58 ` Richard Sandiford 2007-01-10 12:00 ` [ColdFire 45/63] Set TARGET_ASM_FILE_START_APP_OFF to false for GNU/Linux Richard Sandiford 2007-01-11 17:50 ` [ColdFire 44/63] Remove unncessary saves and restores of %a5 Jeffrey Law 2007-01-10 17:58 ` [ColdFire 43/63] Use floating-point branches on ColdFire too Jeffrey Law 1 sibling, 2 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 11:58 UTC (permalink / raw) To: gcc-patches As mentioned previously, there is code to make sure that the PIC register is always saved and restored by nonleaf functions if TARGET_ID_SHARED_LIBRARY. This special case is no longer needed because the GOT loads have been separated out from the call patterns. Richard gcc/ * config/m68k/m68k.c (m68k_save_reg): Remove special case for leaf functions. (m68k_expand_prologue): Likewise. Index: gcc/config/m68k/m68k.c =================================================================== --- gcc/config/m68k/m68k.c 2007-01-09 15:02:19.000000000 +0000 +++ gcc/config/m68k/m68k.c 2007-01-09 15:02:20.000000000 +0000 @@ -749,8 +749,6 @@ m68k_save_reg (unsigned int regno, bool { if (current_function_uses_pic_offset_table) return true; - if (!current_function_is_leaf && TARGET_ID_SHARED_LIBRARY) - return true; } if (current_function_calls_eh_return) @@ -996,8 +994,7 @@ m68k_expand_prologue (void) if (flag_pic && !TARGET_SEP_DATA - && (current_function_uses_pic_offset_table - || (!current_function_is_leaf && TARGET_ID_SHARED_LIBRARY))) + && current_function_uses_pic_offset_table) { insn = emit_insn (gen_load_got (pic_offset_table_rtx)); REG_NOTES (insn) = gen_rtx_EXPR_LIST (REG_MAYBE_DEAD, ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 45/63] Set TARGET_ASM_FILE_START_APP_OFF to false for GNU/Linux 2007-01-10 11:58 ` [ColdFire 44/63] Remove unncessary saves and restores of %a5 Richard Sandiford @ 2007-01-10 12:00 ` Richard Sandiford 2007-01-10 12:01 ` [ColdFire 46/63] Add support for unwinding through signal handlers Richard Sandiford ` (2 more replies) 2007-01-11 17:50 ` [ColdFire 44/63] Remove unncessary saves and restores of %a5 Jeffrey Law 1 sibling, 3 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 12:00 UTC (permalink / raw) To: gcc-patches The m68k port defaults to "# APP OFF". However, it can't compile glibc in that state, because glibc uses comments to hide section attributes. TARGET_ASM_FILE_START_APP_OFF is already an OS-style target hook -- the default is protected by an #ifdef guard -- so this patch simply moves the m68k definition from m68k.c to m68k.h and overrides it in linux.h. Richard gcc/ * config/m68k/m68k.h (TARGET_ASM_FILE_START_APP_OFF): Define. * config/m68k/linux.h (TARGET_ASM_FILE_START_APP_OFF): Override. * config/m68k/m68k.c (TARGET_ASM_FILE_START_APP_OFF): Delete. Index: gcc/config/m68k/m68k.h =================================================================== --- gcc/config/m68k/m68k.h 2007-01-09 15:02:18.000000000 +0000 +++ gcc/config/m68k/m68k.h 2007-01-09 15:02:20.000000000 +0000 @@ -936,6 +936,7 @@ #define REGISTER_PREFIX "" #define LOCAL_LABEL_PREFIX "" #define USER_LABEL_PREFIX "_" #define IMMEDIATE_PREFIX "#" +#define TARGET_ASM_FILE_START_APP_OFF true #define REGISTER_NAMES \ {REGISTER_PREFIX"d0", REGISTER_PREFIX"d1", REGISTER_PREFIX"d2", \ Index: gcc/config/m68k/linux.h =================================================================== --- gcc/config/m68k/linux.h 2007-01-09 15:02:13.000000000 +0000 +++ gcc/config/m68k/linux.h 2007-01-09 15:02:20.000000000 +0000 @@ -229,3 +229,8 @@ #define CLEAR_INSN_CACHE(BEG, END) \ } #define TARGET_ASM_FILE_END file_end_indicate_exec_stack + +/* glibc uses comments to hide section attributes. So setting + ASM_FILE_START_APP_OFF breaks it. */ +#undef TARGET_ASM_FILE_START_APP_OFF +#define TARGET_ASM_FILE_START_APP_OFF false Index: gcc/config/m68k/m68k.c =================================================================== --- gcc/config/m68k/m68k.c 2007-01-09 15:02:20.000000000 +0000 +++ gcc/config/m68k/m68k.c 2007-01-09 15:02:20.000000000 +0000 @@ -193,9 +193,6 @@ #define TARGET_ASM_OUTPUT_MI_THUNK m68k_ #undef TARGET_ASM_CAN_OUTPUT_MI_THUNK #define TARGET_ASM_CAN_OUTPUT_MI_THUNK default_can_output_mi_thunk_no_vcall -#undef TARGET_ASM_FILE_START_APP_OFF -#define TARGET_ASM_FILE_START_APP_OFF true - #undef TARGET_DEFAULT_TARGET_FLAGS #define TARGET_DEFAULT_TARGET_FLAGS MASK_STRICT_ALIGNMENT #undef TARGET_HANDLE_OPTION ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 46/63] Add support for unwinding through signal handlers 2007-01-10 12:00 ` [ColdFire 45/63] Set TARGET_ASM_FILE_START_APP_OFF to false for GNU/Linux Richard Sandiford @ 2007-01-10 12:01 ` Richard Sandiford 2007-01-10 12:03 ` [ColdFire 47/63] Fix PR target/28181 Richard Sandiford 2007-01-16 1:38 ` [ColdFire 46/63] Add support for unwinding through signal handlers Roman Zippel 2007-01-10 17:59 ` [ColdFire 45/63] Set TARGET_ASM_FILE_START_APP_OFF to false for GNU/Linux Jeffrey Law 2007-01-10 18:28 ` Andreas Schwab 2 siblings, 2 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 12:01 UTC (permalink / raw) To: gcc-patches This patch adds support for unwinding through linux signal trampolines. Only the ColdFire version has been properly tested, but I hope the 680x0 version stands a good chance of being OK. Richard gcc/ * config/m68k/linux.h (MD_UNWIND_SUPPORT): Define. * config/m68k/linux-unwind.h: New file. Index: gcc/config/m68k/linux.h =================================================================== --- gcc/config/m68k/linux.h 2007-01-09 15:02:20.000000000 +0000 +++ gcc/config/m68k/linux.h 2007-01-09 15:02:21.000000000 +0000 @@ -234,3 +234,5 @@ #define TARGET_ASM_FILE_END file_end_ind ASM_FILE_START_APP_OFF breaks it. */ #undef TARGET_ASM_FILE_START_APP_OFF #define TARGET_ASM_FILE_START_APP_OFF false + +#define MD_UNWIND_SUPPORT "config/m68k/linux-unwind.h" Index: gcc/config/m68k/linux-unwind.h =================================================================== --- /dev/null 2007-01-09 03:39:34.548096750 +0000 +++ gcc/config/m68k/linux-unwind.h 2007-01-09 15:02:21.000000000 +0000 @@ -0,0 +1,129 @@ +/* DWARF2 EH unwinding support for m68k Linux. + Copyright (C) 2006 Free Software Foundation, Inc. + +This file is part of GCC. + +GCC is free software; you can redistribute it and/or modify +it under the terms of the GNU General Public License as published by +the Free Software Foundation; either version 2, or (at your option) +any later version. + +In addition to the permissions in the GNU General Public License, the +Free Software Foundation gives you unlimited permission to link the +compiled version of this file with other programs, and to distribute +those programs without any restriction coming from the use of this +file. (The General Public License restrictions do apply in other +respects; for example, they cover modification of the file, and +distribution when not linked into another program.) + +GCC is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. + +You should have received a copy of the GNU General Public License +along with GCC; see the file COPYING. If not, write to +the Free Software Foundation, 51 Franklin Street, Fifth Floor, +Boston, MA 02110-1301, USA. */ + +#ifndef inhibit_libc +#include <signal.h> +#include <asm/unistd.h> + +#define MD_FALLBACK_FRAME_STATE_FOR m68k_fallback_frame_state + +struct sigframe_footer { + char retcode[8]; + unsigned long extramask[1]; + struct sigcontext sc; +}; + +struct rt_sigframe_footer { + char retcode[8]; + struct siginfo info; + struct ucontext uc; +}; + +static _Unwind_Reason_Code +m68k_fallback_frame_state (struct _Unwind_Context *context, + _Unwind_FrameState *fs) +{ + unsigned short *pc; + _Unwind_Ptr new_cfa, base; + int i; + + pc = (unsigned short *) context->ra; + + /* Check for: + + moveq #__NR_sigreturn, %d0 (70xx) + trap #0 (4e40) */ + if (pc[0] == (0x7000 | __NR_sigreturn) && pc[1] == 0x4e40) + { + struct sigcontext *sc; + + sc = &((struct sigframe_footer *) context->ra)->sc; + + new_cfa = (_Unwind_Ptr) sc; + fs->regs.cfa_how = CFA_REG_OFFSET; + fs->regs.cfa_reg = STACK_POINTER_REGNUM; + fs->regs.cfa_offset = new_cfa - (_Unwind_Ptr) context->cfa; + + fs->regs.reg[25].how = REG_SAVED_OFFSET; + fs->regs.reg[25].loc.offset = (_Unwind_Ptr) &sc->sc_pc - new_cfa; + fs->retaddr_column = 25; + + return _URC_NO_REASON; + } + /* ColdFire kernels use the sequence: + + move.l #__NR_rt_sigreturn, %d0 (203c xxxx xxxx) + trap #0 (4e40) + + 680x0 kernels use: + + moveq #__NR_rt_sigreturn ^ 0xff, %d0 (70xx) + not.b %d0 (4600) + trap #0 (4e40) */ +#ifdef __mcoldfire__ + else if (pc[0] == 0x203c + && pc[1] == 0x0000 + && pc[2] == __NR_rt_sigreturn + && pc[3] == 0x4e40) +#else + else if (pc[0] == (0x7000 | (__NR_rt_sigreturn ^ 0xff)) + && pc[1] == 0x4600 + && pc[2] == 0x4e40) +#endif + { + mcontext_t *mc; + + mc = &((struct rt_sigframe_footer *) context->ra)->uc.uc_mcontext; + + new_cfa = (_Unwind_Ptr) mc; + fs->regs.cfa_how = CFA_REG_OFFSET; + fs->regs.cfa_reg = STACK_POINTER_REGNUM; + fs->regs.cfa_offset = new_cfa - (_Unwind_Ptr) context->cfa; + + base = (_Unwind_Ptr) mc->gregs - new_cfa; + for (i = 0; i < 16; i++) + { + fs->regs.reg[i].how = REG_SAVED_OFFSET; + fs->regs.reg[i].loc.offset = base + i * 4; + } + fs->regs.reg[25].how = REG_SAVED_OFFSET; + fs->regs.reg[25].loc.offset = base + R_PC * 4; + fs->retaddr_column = 25; + + for (i = 0; i < 8; i++) + { + base = (_Unwind_Ptr) &mc->fpregs.f_fpregs[i] - new_cfa; + fs->regs.reg[i + 16].how = REG_SAVED_OFFSET; + fs->regs.reg[i + 16].loc.offset = base; + } + return _URC_NO_REASON; + } + else + return _URC_END_OF_STACK; +} +#endif ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 47/63] Fix PR target/28181 2007-01-10 12:01 ` [ColdFire 46/63] Add support for unwinding through signal handlers Richard Sandiford @ 2007-01-10 12:03 ` Richard Sandiford 2007-01-10 12:04 ` [ColdFire 48/63] Fix the 'T' constraint Richard Sandiford 2007-01-16 18:16 ` [ColdFire 47/63] Fix PR target/28181 Jeffrey Law 2007-01-16 1:38 ` [ColdFire 46/63] Add support for unwinding through signal handlers Roman Zippel 1 sibling, 2 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 12:03 UTC (permalink / raw) To: gcc-patches; +Cc: rask, zippel This patch fixes PR target/28181. See the thread starting at: http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00766.html for previous discussion about this PR. The problem is that we may sometimes need to reload paradoxical HImode or SImode subregs of spilled QImode pseudos. reload sees no reason not to generate such reloads for address registers because address registers are allowed to store HImode and SImode values. However, it may then decide to reload the inner QImode spill slot rather than an HImode or SImode MEM. Such loads cannot be done with address registers. As I said in my follow-up to the above message, I think the correct fix is to (a) allow address registers to hold bytes and (b) to define SECONDARY_RELOAD_CLASS in such a way that we require a DATA_REGS temporary when loading or storing them. No change is needed to the movqi patterns because they already handle moves from constants to address registers, and between address registers and data registers, despite what m68k_regno_mode_ok says. Richard gcc/ PR target/28181 * config/m68k/m68k-protos.h (m68k_secondary_reload_class): Declare. (m68k_preferred_reload_class): Likewise. * config/m68k/m68k.h (HARD_REGNO_MODE_OK): Remove duplicated comment. (SECONDARY_RELOAD_CLASS): Define. (PREFERRED_RELOAD_CLASS): Use m68k_preferred_reload_class. (LIMIT_RELOAD_CLASS): Delete. * config/m68k/m68k.c (m68k_regno_mode_ok): Don't prevent address registers from storing bytes. (m68k_secondary_reload_class): New function. (m68k_preferred_reload_class): Likewise. gcc/testsuite/ * gcc.c-torture/compile/m68k-byte-addr.c: New test. Index: gcc/config/m68k/m68k-protos.h =================================================================== --- gcc/config/m68k/m68k-protos.h 2007-01-09 15:02:19.000000000 +0000 +++ gcc/config/m68k/m68k-protos.h 2007-01-09 15:02:22.000000000 +0000 @@ -66,6 +66,9 @@ extern const char *m68k_output_movem (rt #endif /* RTX_CODE */ extern bool m68k_regno_mode_ok (int, enum machine_mode); +extern enum reg_class m68k_secondary_reload_class (enum reg_class, + enum machine_mode, rtx); +extern enum reg_class m68k_preferred_reload_class (rtx, enum reg_class); extern int flags_in_68881 (void); extern void m68k_expand_prologue (void); extern bool m68k_use_return_insn (void); Index: gcc/config/m68k/m68k.h =================================================================== --- gcc/config/m68k/m68k.h 2007-01-09 15:02:20.000000000 +0000 +++ gcc/config/m68k/m68k.h 2007-01-09 15:02:22.000000000 +0000 @@ -399,13 +399,12 @@ #define HARD_REGNO_NREGS(REGNO, MODE) #define HARD_REGNO_RENAME_OK(OLD_REG, NEW_REG) \ m68k_hard_regno_rename_ok (OLD_REG, NEW_REG) -/* Value is true if hard register REGNO can hold a value of machine-mode MODE. - On the 68000, the cpu registers can hold any mode except bytes in - address registers, the 68881 registers can hold only SFmode or DFmode. */ - #define HARD_REGNO_MODE_OK(REGNO, MODE) \ m68k_regno_mode_ok ((REGNO), (MODE)) +#define SECONDARY_RELOAD_CLASS(CLASS, MODE, X) \ + m68k_secondary_reload_class (CLASS, MODE, X) + #define MODES_TIEABLE_P(MODE1, MODE2) \ (! TARGET_HARD_FLOAT \ || ((GET_MODE_CLASS (MODE1) == MODE_FLOAT \ @@ -542,34 +541,8 @@ #define EXTRA_CONSTRAINT(OP,CODE) \ ? const_call_operand (OP, VOIDmode) \ : 0) -/* On the m68k, use a data reg if possible when the - value is a constant in the range where moveq could be used - and we ensure that QImodes are reloaded into data regs. */ -#define PREFERRED_RELOAD_CLASS(X,CLASS) \ - ((GET_CODE (X) == CONST_INT \ - && (unsigned) (INTVAL (X) + 0x80) < 0x100 \ - && (CLASS) != ADDR_REGS) \ - ? DATA_REGS \ - : (GET_MODE (X) == QImode && (CLASS) != ADDR_REGS) \ - ? DATA_REGS \ - : (GET_CODE (X) == CONST_DOUBLE \ - && GET_MODE_CLASS (GET_MODE (X)) == MODE_FLOAT) \ - ? (TARGET_HARD_FLOAT && (CLASS == FP_REGS || CLASS == DATA_OR_FP_REGS) \ - ? FP_REGS : NO_REGS) \ - : (TARGET_PCREL \ - && (GET_CODE (X) == SYMBOL_REF || GET_CODE (X) == CONST \ - || GET_CODE (X) == LABEL_REF)) \ - ? ADDR_REGS \ - : (CLASS)) - -/* Force QImode output reloads from subregs to be allocated to data regs, - since QImode stores from address regs are not supported. We make the - assumption that if the class is not ADDR_REGS, then it must be a superset - of DATA_REGS. */ -#define LIMIT_RELOAD_CLASS(MODE, CLASS) \ - (((MODE) == QImode && (CLASS) != ADDR_REGS) \ - ? DATA_REGS \ - : (CLASS)) +#define PREFERRED_RELOAD_CLASS(X,CLASS) \ + m68k_preferred_reload_class (X, CLASS) /* On the m68k, this is the size of MODE in words, except in the FP regs, where a single reg is always enough. */ Index: gcc/config/m68k/m68k.c =================================================================== --- gcc/config/m68k/m68k.c 2007-01-09 15:02:20.000000000 +0000 +++ gcc/config/m68k/m68k.c 2007-01-09 15:02:22.000000000 +0000 @@ -4115,9 +4115,10 @@ m68k_hard_regno_rename_ok (unsigned int return 1; } -/* Value is true if hard register REGNO can hold a value of machine-mode MODE. - On the 68000, the cpu registers can hold any mode except bytes in address - registers, but the 68881 registers can hold only SFmode or DFmode. */ +/* Value is true if hard register REGNO can hold a value of machine-mode + MODE. On the 68000, we let the cpu registers can hold any mode, but + restrict the 68881 registers to floating-point modes. */ + bool m68k_regno_mode_ok (int regno, enum machine_mode mode) { @@ -4129,10 +4130,6 @@ m68k_regno_mode_ok (int regno, enum mach } else if (ADDRESS_REGNO_P (regno)) { - /* Address Registers, can't hold bytes, can hold aggregate if - fits in. */ - if (GET_MODE_SIZE (mode) == 1) - return false; if (regno + GET_MODE_SIZE (mode) / 4 <= 16) return true; } @@ -4148,6 +4145,66 @@ m68k_regno_mode_ok (int regno, enum mach return false; } +/* Implement SECONDARY_RELOAD_CLASS. */ + +enum reg_class +m68k_secondary_reload_class (enum reg_class rclass, + enum machine_mode mode, rtx x) +{ + int regno; + + regno = true_regnum (x); + + /* If one operand of a movqi is an address register, the other + operand must be a general register or constant. Other types + of operand must be reloaded through a data register. */ + if (GET_MODE_SIZE (mode) == 1 + && reg_classes_intersect_p (rclass, ADDR_REGS) + && !(INT_REGNO_P (regno) || CONSTANT_P (x))) + return DATA_REGS; + + /* PC-relative addresses must be loaded into an address register first. */ + if (TARGET_PCREL + && !reg_class_subset_p (rclass, ADDR_REGS) + && symbolic_operand (x, VOIDmode)) + return ADDR_REGS; + + return NO_REGS; +} + +/* Implement PREFERRED_RELOAD_CLASS. */ + +enum reg_class +m68k_preferred_reload_class (rtx x, enum reg_class rclass) +{ + enum reg_class secondary_class; + + /* If RCLASS might need a secondary reload, try restricting it to + a class that doesn't. */ + secondary_class = m68k_secondary_reload_class (rclass, GET_MODE (x), x); + if (secondary_class != NO_REGS + && reg_class_subset_p (secondary_class, rclass)) + return secondary_class; + + /* Prefer to use moveq for in-range constants. */ + if (GET_CODE (x) == CONST_INT + && reg_class_subset_p (DATA_REGS, rclass) + && IN_RANGE (INTVAL (x), -0x80, 0x7f)) + return DATA_REGS; + + /* ??? Do we really need this now? */ + if (GET_CODE (x) == CONST_DOUBLE + && GET_MODE_CLASS (GET_MODE (x)) == MODE_FLOAT) + { + if (TARGET_HARD_FLOAT && reg_class_subset_p (FP_REGS, rclass)) + return FP_REGS; + + return NO_REGS; + } + + return rclass; +} + /* Return floating point values in a 68881 register. This makes 68881 code a little bit faster. It also makes -msoft-float code incompatible with hard-float code, so people have to be careful not to mix the two. Index: gcc/testsuite/gcc.c-torture/compile/m68k-byte-addr.c =================================================================== --- /dev/null 2007-01-09 03:39:34.548096750 +0000 +++ gcc/testsuite/gcc.c-torture/compile/m68k-byte-addr.c 2007-01-09 15:02:22.000000000 +0000 @@ -0,0 +1,20 @@ +/* This testcase triggered an attempt to reload a byte value into an + address register. */ +extern volatile unsigned char x[]; + +#define DECLARE(I) orig##I, inc##I +#define READ(I) orig##I = x[I] +#define INC(I) inc##I = orig##I + 1 +#define WRITE1(I) x[I] = orig##I +#define WRITE2(I) x[I] = inc##I + +#define REPEAT(X) X(0), X(1), X(2), X(3), X(4), X(5), X(6), X(7), X(8) + +void foo (void) +{ + unsigned char REPEAT (DECLARE); + REPEAT (READ); + REPEAT (INC); + REPEAT (WRITE1); + REPEAT (WRITE2); +} ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 48/63] Fix the 'T' constraint 2007-01-10 12:03 ` [ColdFire 47/63] Fix PR target/28181 Richard Sandiford @ 2007-01-10 12:04 ` Richard Sandiford 2007-01-10 12:06 ` [ColdFire 49/63] Save and restore the PIC register when using a constant pool Richard Sandiford 2007-01-10 18:47 ` [ColdFire 48/63] Fix the 'T' constraint Jeffrey Law 2007-01-16 18:16 ` [ColdFire 47/63] Fix PR target/28181 Jeffrey Law 1 sibling, 2 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 12:04 UTC (permalink / raw) To: gcc-patches After having misapplied a patch, I came across a bug in which 'T' was allowing symbolic constants for non-pcrel PIC. The comment reads: `T' is for operands that satisfy 's' when -mpcrel is not in effect. and 's' doesn't accept anything if flag_pic. This bug became latent again once I'd fixed my initial mistake, but I still think it should be fixed. Richard gcc/ * config/m68k/m68k.h (EXTRA_CONSTRAINT): Stop the 'T' constraint from accepting 's' constraints if flag_pic. Index: gcc/config/m68k/m68k.h =================================================================== --- gcc/config/m68k/m68k.h 2007-01-09 15:02:22.000000000 +0000 +++ gcc/config/m68k/m68k.h 2007-01-09 15:02:23.000000000 +0000 @@ -526,7 +526,7 @@ #define EXTRA_CONSTRAINT(OP,CODE) \ || GET_CODE (XEXP (OP, 0)) == CONST)) \ : \ (CODE) == 'T' \ - ? ( !TARGET_PCREL \ + ? (!flag_pic \ && (GET_CODE (OP) == SYMBOL_REF \ || GET_CODE (OP) == LABEL_REF \ || GET_CODE (OP) == CONST)) \ ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 49/63] Save and restore the PIC register when using a constant pool 2007-01-10 12:04 ` [ColdFire 48/63] Fix the 'T' constraint Richard Sandiford @ 2007-01-10 12:06 ` Richard Sandiford 2007-01-10 12:07 ` [ColdFire 50/63] Save the PIC register for __builtin_eh_return Richard Sandiford 2007-01-11 17:52 ` [ColdFire 49/63] Save and restore the PIC register when using a constant pool Jeffrey Law 2007-01-10 18:47 ` [ColdFire 48/63] Fix the 'T' constraint Jeffrey Law 1 sibling, 2 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 12:06 UTC (permalink / raw) To: gcc-patches Reload can legitimately introduce constant pool references into a function that didn't otherwise have them. We're interested in three events when this happens: (a) reload decides to force something into the constant pool (b) reload and config/m68k together decide the final frame layout (c) reload emits the input and output reload instructions These events happen in the order listed. When generating PIC, the PIC form of the address is introduced by (c), which in turn sets current_function_uses_pic_offset_table. However, we need to know in (b) whether to save the PIC register. AIUI, the canonical way of dealing with this is to check current_function_uses_const_pool. Richard gcc/ * config/m68k/m68k.c (m68k_save_reg): Save the PIC register in functions that need a constant pool. Index: gcc/config/m68k/m68k.c =================================================================== --- gcc/config/m68k/m68k.c 2007-01-09 15:02:22.000000000 +0000 +++ gcc/config/m68k/m68k.c 2007-01-09 15:02:23.000000000 +0000 @@ -746,6 +746,13 @@ m68k_save_reg (unsigned int regno, bool { if (current_function_uses_pic_offset_table) return true; + /* Reload may introduce constant pool references into a function + that thitherto didn't need a PIC register. Note that the test + above will not catch that case because we will only set + current_function_uses_pic_offset_table when emitting + the address reloads. */ + if (current_function_uses_const_pool) + return true; } if (current_function_calls_eh_return) ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 50/63] Save the PIC register for __builtin_eh_return 2007-01-10 12:06 ` [ColdFire 49/63] Save and restore the PIC register when using a constant pool Richard Sandiford @ 2007-01-10 12:07 ` Richard Sandiford 2007-01-10 12:08 ` [ColdFire 51/63] Don't use move.l CCs for SFmode comparisons Richard Sandiford ` (2 more replies) 2007-01-11 17:52 ` [ColdFire 49/63] Save and restore the PIC register when using a constant pool Jeffrey Law 1 sibling, 3 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 12:07 UTC (permalink / raw) To: gcc-patches g++.dg/eh/registers1.C showed that we weren't restoring %a5 on EH return. This is because _Unwind_RaiseException was compiled as PIC, and we didn't think it needed to save and restore the PIC register. There was therefore no stack slot in which to set up the value of %a5 on EH return. Richard gcc/ * config/m68k/m68k.c (m68k_save_reg): Save the PIC register in functions that call eh_return. Index: gcc/config/m68k/m68k.c =================================================================== --- gcc/config/m68k/m68k.c 2007-01-09 15:02:23.000000000 +0000 +++ gcc/config/m68k/m68k.c 2007-01-09 15:02:23.000000000 +0000 @@ -744,6 +744,9 @@ m68k_save_reg (unsigned int regno, bool { if (flag_pic && regno == PIC_OFFSET_TABLE_REGNUM) { + /* We need to restore the PIC register on exceptional returns. */ + if (current_function_calls_eh_return) + return true; if (current_function_uses_pic_offset_table) return true; /* Reload may introduce constant pool references into a function ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 51/63] Don't use move.l CCs for SFmode comparisons 2007-01-10 12:07 ` [ColdFire 50/63] Save the PIC register for __builtin_eh_return Richard Sandiford @ 2007-01-10 12:08 ` Richard Sandiford 2007-01-10 12:09 ` [ColdFire 52/63] Don't use neg.l and negx.l on memory for ColdFire Richard Sandiford 2007-01-10 18:48 ` [ColdFire 51/63] Don't use move.l CCs for SFmode comparisons Jeffrey Law 2007-01-10 19:20 ` [ColdFire 50/63] Save the PIC register for __builtin_eh_return Jeffrey Law 2007-01-22 17:52 ` Roman Zippel 2 siblings, 2 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 12:08 UTC (permalink / raw) To: gcc-patches One of the glibc tests showed up a miscompilation of csinhf. notice_update_cc thought that the cc result of a move.l could be used to implement an SFmode comparison, which is wrong for the reason explained in the patch. Richard gcc/ * config/m68k/m68k.c (notice_update_cc): If an SFmode move is implemented using move.l, do not use its cc result for floating-point comparisons. Index: gcc/config/m68k/m68k.c =================================================================== --- gcc/config/m68k/m68k.c 2007-01-09 15:02:23.000000000 +0000 +++ gcc/config/m68k/m68k.c 2007-01-09 15:02:24.000000000 +0000 @@ -3256,12 +3256,18 @@ notice_update_cc (rtx exp, rtx insn) if (cc_status.value2 && modified_in_p (cc_status.value2, insn)) cc_status.value2 = 0; } + /* fmoves to memory or data registers do not set the condition + codes. Normal moves _do_ set the condition codes, but not in + a way that is appropriate for comparison with 0, because -0.0 + would be treated as a negative nonzero number. Note that it + isn't appropriate to conditionalize this restiction on + HONOR_SIGNED_ZEROS because that macro merely indicates whether + we care about the difference between -0.0 and +0.0. */ else if (!FP_REG_P (SET_DEST (exp)) && SET_DEST (exp) != cc0_rtx && (FP_REG_P (SET_SRC (exp)) || GET_CODE (SET_SRC (exp)) == FIX - || GET_CODE (SET_SRC (exp)) == FLOAT_TRUNCATE - || GET_CODE (SET_SRC (exp)) == FLOAT_EXTEND)) + || FLOAT_MODE_P (GET_MODE (SET_DEST (exp))))) CC_STATUS_INIT; /* A pair of move insns doesn't produce a useful overall cc. */ else if (!FP_REG_P (SET_DEST (exp)) ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 52/63] Don't use neg.l and negx.l on memory for ColdFire 2007-01-10 12:08 ` [ColdFire 51/63] Don't use move.l CCs for SFmode comparisons Richard Sandiford @ 2007-01-10 12:09 ` Richard Sandiford 2007-01-10 12:10 ` [ColdFire 53/63] Static chain fixes Richard Sandiford 2007-01-11 17:54 ` [ColdFire 52/63] Don't use neg.l and negx.l on memory for ColdFire Jeffrey Law 2007-01-10 18:48 ` [ColdFire 51/63] Don't use move.l CCs for SFmode comparisons Jeffrey Law 1 sibling, 2 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 12:09 UTC (permalink / raw) To: gcc-patches The testsuite had cases in which ColdFire targets would try to use neg.l and negx.l on memory operands. The patch fixes this by splitting adddi_dilshr32 into ColdFire and non-ColdFire patterns and only allowing register destinations in the former. I also checked for other uses of {add,sub,neg}x.l with memory operands. The only two I could find were in the adddi3 and subdi3 patterns, which supposedly allow both asm operands to be pre-decrement. However, I think those alternatives are dead code now; flow doesn't use pre-decrement addressing for an operand if another operand mentions the same register. (This is true regardless of whether the two operands are matching operands.) Thus operand 2 might be a pre-decrement, but because operands 0 and 1 must be the same address, operand 0 won't be a pre-decrement. FWIW, to make sure, I verified this on the obvious testcase. I've just removed those alternatives for clarity. Richard gcc/ * config/m68k/m68k.md (adddi_dilshr32): Rename to... (*adddi_dilshr32): ...this. Fix formatting. Remove commented-out non-canonical pattern. Restrict to !TARGET_COLDFIRE. (*adddi_dilshr32_cf): New pattern. (adddi3, subdi3): Remove first alternatives. gcc/testsuite/ * gcc.c-torture/compile/20061214-1.c: New test. Index: gcc/config/m68k/m68k.md =================================================================== --- gcc/config/m68k/m68k.md 2007-01-09 15:02:20.000000000 +0000 +++ gcc/config/m68k/m68k.md 2007-01-09 15:02:24.000000000 +0000 @@ -1936,15 +1936,12 @@ (define_insn "adddi_sexthishl32" return "move%.w %1,%3\;ext%.l %3\;add%.l %3,%0"; }) -(define_insn "adddi_dilshr32" +(define_insn "*adddi_dilshr32" [(set (match_operand:DI 0 "nonimmediate_operand" "=d,o") -;; (plus:DI (match_operand:DI 2 "general_operand" "%0") -;; (lshiftrt:DI (match_operand:DI 1 "general_operand" "ro") -;; (const_int 32))))] - (plus:DI (lshiftrt:DI (match_operand:DI 1 "general_operand" "ro,d") - (const_int 32)) - (match_operand:DI 2 "general_operand" "0,0")))] - "" + (plus:DI (lshiftrt:DI (match_operand:DI 1 "general_operand" "ro,d") + (const_int 32)) + (match_operand:DI 2 "general_operand" "0,0")))] + "!TARGET_COLDFIRE" { CC_STATUS_INIT; if (GET_CODE (operands[0]) == REG) @@ -1954,6 +1951,17 @@ (define_insn "adddi_dilshr32" return "add%.l %1,%2\;negx%.l %0\;neg%.l %0"; }) +(define_insn "*adddi_dilshr32_cf" + [(set (match_operand:DI 0 "register_operand" "=d") + (plus:DI (lshiftrt:DI (match_operand:DI 1 "nonimmediate_operand" "ro") + (const_int 32)) + (match_operand:DI 2 "register_operand" "0")))] + "TARGET_COLDFIRE" +{ + CC_STATUS_INIT; + return "add%.l %1,%R0\;negx%.l %0\;neg%.l %0"; +}) + (define_insn "adddi_dishl32" [(set (match_operand:DI 0 "nonimmediate_operand" "=r,o") ;; (plus:DI (match_operand:DI 2 "general_operand" "%0") @@ -1973,10 +1981,10 @@ (define_insn "adddi_dishl32" }) (define_insn "adddi3" - [(set (match_operand:DI 0 "nonimmediate_operand" "=<,o<>,d,d,d") - (plus:DI (match_operand:DI 1 "general_operand" "%0,0,0,0,0") - (match_operand:DI 2 "general_operand" "<,d,no>,d,a"))) - (clobber (match_scratch:SI 3 "=X,&d,&d,X,&d"))] + [(set (match_operand:DI 0 "nonimmediate_operand" "=o<>,d,d,d") + (plus:DI (match_operand:DI 1 "general_operand" "%0,0,0,0") + (match_operand:DI 2 "general_operand" "d,no>,d,a"))) + (clobber (match_scratch:SI 3 "=&d,&d,X,&d"))] "" { if (DATA_REG_P (operands[0])) @@ -2029,9 +2037,6 @@ (define_insn "adddi3" else { gcc_assert (GET_CODE (operands[0]) == MEM); - if (GET_CODE (operands[2]) == MEM - && GET_CODE (XEXP (operands[2], 0)) == PRE_DEC) - return "add%.l %2,%0\;addx%.l %2,%0"; CC_STATUS_INIT; if (GET_CODE (XEXP (operands[0], 0)) == POST_INC) { @@ -2418,10 +2423,10 @@ (define_insn "subdi_dishl32" }) (define_insn "subdi3" - [(set (match_operand:DI 0 "nonimmediate_operand" "=<,o<>,d,d,d") - (minus:DI (match_operand:DI 1 "general_operand" "0,0,0,0,0") - (match_operand:DI 2 "general_operand" "<,d,no>,d,a"))) - (clobber (match_scratch:SI 3 "=X,&d,&d,X,&d"))] + [(set (match_operand:DI 0 "nonimmediate_operand" "=o<>,d,d,d") + (minus:DI (match_operand:DI 1 "general_operand" "0,0,0,0") + (match_operand:DI 2 "general_operand" "d,no>,d,a"))) + (clobber (match_scratch:SI 3 "=&d,&d,X,&d"))] "" { if (DATA_REG_P (operands[0])) @@ -2476,9 +2481,6 @@ (define_insn "subdi3" else { gcc_assert (GET_CODE (operands[0]) == MEM); - if (GET_CODE (operands[2]) == MEM - && GET_CODE (XEXP (operands[2], 0)) == PRE_DEC) - return "sub%.l %2,%0\;subx%.l %2,%0"; CC_STATUS_INIT; if (GET_CODE (XEXP (operands[0], 0)) == POST_INC) { ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 53/63] Static chain fixes 2007-01-10 12:09 ` [ColdFire 52/63] Don't use neg.l and negx.l on memory for ColdFire Richard Sandiford @ 2007-01-10 12:10 ` Richard Sandiford 2007-01-10 12:11 ` [ColdFire 54/63] Define PREFERRED_STACK_BOUNDARY Richard Sandiford 2007-01-10 19:19 ` [ColdFire 53/63] Static chain fixes Jeffrey Law 2007-01-11 17:54 ` [ColdFire 52/63] Don't use neg.l and negx.l on memory for ColdFire Jeffrey Law 1 sibling, 2 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 12:10 UTC (permalink / raw) To: gcc-patches m68k*-elf targets use %a0 as both the incoming structure return address _and_ the static chain pointer. This causes a conflict if a nested function returns a structure. This patch moves the static chain register to %a1 for these targets only. It also generalises the template code to cope with static chain registers other than %a0. Richard gcc/ 200x-xx-xx Nathan Sidwell <nathan@codesourcery.com> Richard Sandiford <richard@codesourcery.com> * config/m68k/m68k.h (M68K_STATIC_CHAIN_REG_NAME): New macro. (INITIALIZE_TRAMPOLINE): Use STATIC_CHAIN_REGNUM. (__transfer_from_trampoline): Use M68K_STATIC_CHAIN_REG_NAME. * config/m68k/m68kelf.h (STATIC_CHAIN_REGNUM): Override. (M68K_STATIC_CHAIN_REG_NAME): Likewise. * config/m68k/netbsd-elf.h (M68K_STATIC_CHAIN_REG_NAME): Likewise. gcc/testsuite/ 200x-xx-xx Nathan Sidwell <nathan@codesourcery.com> * gcc.c-torture/execute/nestfunc-7.c: New. Index: gcc/config/m68k/m68k.h =================================================================== --- gcc/config/m68k/m68k.h 2007-01-09 15:02:23.000000000 +0000 +++ gcc/config/m68k/m68k.h 2007-01-09 15:02:24.000000000 +0000 @@ -431,6 +431,7 @@ #define FRAME_POINTER_REQUIRED 0 #define ARG_POINTER_REGNUM 24 #define STATIC_CHAIN_REGNUM 8 +#define M68K_STATIC_CHAIN_REG_NAME REGISTER_PREFIX "a0" /* Register in which address to store a structure value is passed to a function. */ @@ -654,7 +655,8 @@ #define FINALIZE_TRAMPOLINE(TRAMP) jmp FNADDR */ #define INITIALIZE_TRAMPOLINE(TRAMP, FNADDR, CXT) \ { \ - emit_move_insn (gen_rtx_MEM (HImode, TRAMP), GEN_INT(0x207C)); \ + emit_move_insn (gen_rtx_MEM (HImode, TRAMP), \ + GEN_INT(0x207C + ((STATIC_CHAIN_REGNUM-8) << 9))); \ emit_move_insn (gen_rtx_MEM (SImode, plus_constant (TRAMP, 2)), CXT); \ emit_move_insn (gen_rtx_MEM (HImode, plus_constant (TRAMP, 6)), \ GEN_INT(0x4EF9)); \ @@ -677,7 +679,7 @@ #define TRANSFER_FROM_TRAMPOLINE \ void \ __transfer_from_trampoline () \ { \ - register char *a0 asm ("%a0"); \ + register char *a0 asm (M68K_STATIC_CHAIN_REG_NAME); \ asm (GLOBAL_ASM_OP "___trampoline"); \ asm ("___trampoline:"); \ asm volatile ("move%.l %0,%@" : : "m" (a0[22])); \ Index: gcc/config/m68k/m68kelf.h =================================================================== --- gcc/config/m68k/m68kelf.h 2007-01-09 15:02:00.000000000 +0000 +++ gcc/config/m68k/m68kelf.h 2007-01-09 15:02:24.000000000 +0000 @@ -83,6 +83,14 @@ #define ASM_OUTPUT_ALIGN(FILE,LOG) \ #undef M68K_STRUCT_VALUE_REGNUM #define M68K_STRUCT_VALUE_REGNUM 8 +/* The static chain regnum defaults to a0, but we use that for + structure return, so have to use a1 for the static chain. */ + +#undef STATIC_CHAIN_REGNUM +#define STATIC_CHAIN_REGNUM 9 +#undef M68K_STATIC_CHAIN_REG_NAME +#define M68K_STATIC_CHAIN_REG_NAME REGISTER_PREFIX "a1" + #define ASM_COMMENT_START "|" /* Define how the m68k registers should be numbered for Dwarf output. Index: gcc/config/m68k/netbsd-elf.h =================================================================== --- gcc/config/m68k/netbsd-elf.h 2007-01-09 15:02:13.000000000 +0000 +++ gcc/config/m68k/netbsd-elf.h 2007-01-09 15:02:24.000000000 +0000 @@ -233,6 +233,8 @@ #define M68K_STRUCT_VALUE_REGNUM 8 #undef STATIC_CHAIN_REGNUM #define STATIC_CHAIN_REGNUM 9 +#undef M68K_STATIC_CHAIN_REG_NAME +#define M68K_STATIC_CHAIN_REG_NAME REGISTER_PREFIX "a1" /* Now to renumber registers for dbx and gdb. Index: gcc/testsuite/gcc.c-torture/execute/nestfunc-7.c =================================================================== --- /dev/null 2007-01-09 03:39:34.548096750 +0000 +++ gcc/testsuite/gcc.c-torture/execute/nestfunc-7.c 2007-01-09 15:02:24.000000000 +0000 @@ -0,0 +1,44 @@ +struct A +{ + int one; + int two; + int three; + int four; + int five; + int six; +}; + +static int test (void) +{ + int base; + + struct A Foo (void) + { + struct A a; + + a.one = base + 1; + a.two = base + 2; + a.three = base + 3; + a.four = base + 4; + a.five = base + 5; + a.six = base + 6; + + return a; + } + + base = 10; + struct A a = Foo (); + + return (a.one == 11 + && a.two == 12 + && a.three == 13 + && a.four == 14 + && a.five == 15 + && a.six == 16); +} + +int main (void) +{ + return !test (); +} + ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 54/63] Define PREFERRED_STACK_BOUNDARY 2007-01-10 12:10 ` [ColdFire 53/63] Static chain fixes Richard Sandiford @ 2007-01-10 12:11 ` Richard Sandiford 2007-01-10 12:13 ` [ColdFire 55/63] Add support for vcall_offset thunks Richard Sandiford ` (2 more replies) 2007-01-10 19:19 ` [ColdFire 53/63] Static chain fixes Jeffrey Law 1 sibling, 3 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 12:11 UTC (permalink / raw) To: gcc-patches The m68k ABI does not guarantee that the stack is aligned to 4 bytes, but for efficiency reasons, the ColdFire targets strongly prefer it to be. This patch defines PREFERRED_STACK_BOUNDARY accordingly. Richard gcc/ * config/m68k/m68k.h (PREFERRED_STACK_BOUNDARY): Define to 32 for ColdFire targets. Index: gcc/config/m68k/m68k.h =================================================================== --- gcc/config/m68k/m68k.h 2007-01-09 15:02:24.000000000 +0000 +++ gcc/config/m68k/m68k.h 2007-01-09 15:02:25.000000000 +0000 @@ -284,6 +284,8 @@ #define PARM_BOUNDARY (TARGET_SHORT ? 16 #define STACK_BOUNDARY 16 #define FUNCTION_BOUNDARY 16 #define EMPTY_FIELD_BOUNDARY 16 +/* ColdFire strongly prefers a 32-bit aligned stack. */ +#define PREFERRED_STACK_BOUNDARY (TARGET_COLDFIRE ? 32 : 16) /* No data type wants to be aligned rounder than this. Most published ABIs say that ints should be aligned on 16 bit ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 55/63] Add support for vcall_offset thunks 2007-01-10 12:11 ` [ColdFire 54/63] Define PREFERRED_STACK_BOUNDARY Richard Sandiford @ 2007-01-10 12:13 ` Richard Sandiford 2007-01-10 12:15 ` [ColdFire 56/63] ColdFire multilibs and --with-arch Richard Sandiford 2007-01-16 18:14 ` [ColdFire 55/63] Add support for vcall_offset thunks Jeffrey Law 2007-01-10 18:00 ` [ColdFire 54/63] Define PREFERRED_STACK_BOUNDARY Jeffrey Law 2007-01-16 2:35 ` Roman Zippel 2 siblings, 2 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 12:13 UTC (permalink / raw) To: gcc-patches This patch makes m68k_output_mi_thunk hnour vcall_offset. It was easier to do this in rtl than by writing assembly directly, so the patch converts the entire function to use rtl. The main difficulty is in using a call-clobbered PIC register for the duration of the thunk. I've used the same PIC_OFFSET_TABLE_REGNUM trick that x86 and MIPS use. Richard gcc/ * config/m68k/m68k.h (PIC_OFFSET_TABLE_REGNUM): Use the REGNO of pic_offset_table_rtx if reload_completed. (CONDITIONAL_REGISTER_USAGE): Use PIC_REG instead of PIC_OFFSET_TABLE_REGNUM. * config/m68k/m68k.c (TARGET_ASM_CAN_OUTPUT_MI_THUNK): Always return true. (m68k_save_reg): Use PIC_REG instead of PIC_OFFSET_TABLE_REGNO. (m68k_output_mi_thunk): Rewrite to use RTL. Honor vcall_offset. Index: gcc/config/m68k/m68k.h =================================================================== --- gcc/config/m68k/m68k.h 2007-01-09 16:12:15.000000000 +0000 +++ gcc/config/m68k/m68k.h 2007-01-09 16:12:15.000000000 +0000 @@ -316,7 +316,10 @@ #define MAX_LIBRARY_ID 255 #define FIRST_PSEUDO_REGISTER 25 /* All m68k targets (except AmigaOS) use %a5 as the PIC register */ -#define PIC_OFFSET_TABLE_REGNUM (flag_pic ? 13 : INVALID_REGNUM) +#define PIC_OFFSET_TABLE_REGNUM \ + (!flag_pic ? INVALID_REGNUM \ + : reload_completed ? REGNO (pic_offset_table_rtx) \ + : PIC_REG) /* 1 for registers that have pervasive standard uses and are not available for the register allocator. @@ -383,9 +386,8 @@ #define CONDITIONAL_REGISTER_USAGE \ if (TEST_HARD_REG_BIT (x, i)) \ fixed_regs[i] = call_used_regs[i] = 1; \ } \ - if (PIC_OFFSET_TABLE_REGNUM != INVALID_REGNUM) \ - fixed_regs[PIC_OFFSET_TABLE_REGNUM] \ - = call_used_regs[PIC_OFFSET_TABLE_REGNUM] = 1; \ + if (flag_pic) \ + fixed_regs[PIC_REG] = call_used_regs[PIC_REG] = 1; \ } /* On the m68k, ordinary registers hold 32 bits worth; Index: gcc/config/m68k/m68k.c =================================================================== --- gcc/config/m68k/m68k.c 2007-01-09 15:53:34.000000000 +0000 +++ gcc/config/m68k/m68k.c 2007-01-09 20:10:07.000000000 +0000 @@ -191,7 +191,7 @@ #define TARGET_ASM_UNALIGNED_SI_OP TARGE #undef TARGET_ASM_OUTPUT_MI_THUNK #define TARGET_ASM_OUTPUT_MI_THUNK m68k_output_mi_thunk #undef TARGET_ASM_CAN_OUTPUT_MI_THUNK -#define TARGET_ASM_CAN_OUTPUT_MI_THUNK default_can_output_mi_thunk_no_vcall +#define TARGET_ASM_CAN_OUTPUT_MI_THUNK hook_bool_tree_hwi_hwi_tree_true #undef TARGET_DEFAULT_TARGET_FLAGS #define TARGET_DEFAULT_TARGET_FLAGS MASK_STRICT_ALIGNMENT @@ -742,7 +742,7 @@ m68k_initial_elimination_offset (int fro static bool m68k_save_reg (unsigned int regno, bool interrupt_handler) { - if (flag_pic && regno == PIC_OFFSET_TABLE_REGNUM) + if (flag_pic && regno == PIC_REG) { /* We need to restore the PIC register on exceptional returns. */ if (current_function_calls_eh_return) @@ -4050,59 +4050,93 @@ m68k_coff_asm_named_section (const char static void m68k_output_mi_thunk (FILE *file, tree thunk ATTRIBUTE_UNUSED, - HOST_WIDE_INT delta, - HOST_WIDE_INT vcall_offset ATTRIBUTE_UNUSED, + HOST_WIDE_INT delta, HOST_WIDE_INT vcall_offset, tree function) { - rtx xops[1]; - const char *fmt; + rtx this_slot, offset, addr, mem, insn; - if (delta > 0 && delta <= 8) - asm_fprintf (file, (MOTOROLA - ? "\taddq.l %I%d,4(%Rsp)\n" - : "\taddql %I%d,%Rsp@(4)\n"), - (int) delta); - else if (delta < 0 && delta >= -8) - asm_fprintf (file, (MOTOROLA - ? "\tsubq.l %I%d,4(%Rsp)\n" - : "\tsubql %I%d,%Rsp@(4)\n"), - (int) -delta); - else if (TARGET_COLDFIRE) - { - /* ColdFire can't add/sub a constant to memory unless it is in - the range of addq/subq. So load the value into %d0 and - then add it to 4(%sp). */ - if (delta >= -128 && delta <= 127) - asm_fprintf (file, (MOTOROLA - ? "\tmoveq.l %I%wd,%Rd0\n" - : "\tmoveql %I%wd,%Rd0\n"), - delta); - else - asm_fprintf (file, (MOTOROLA - ? "\tmove.l %I%wd,%Rd0\n" - : "\tmovel %I%wd,%Rd0\n"), - delta); - asm_fprintf (file, (MOTOROLA - ? "\tadd.l %Rd0,4(%Rsp)\n" - : "\taddl %Rd0,%Rsp@(4)\n")); + /* Pretend to be a post-reload pass while generating rtl. */ + no_new_pseudos = 1; + reload_completed = 1; + reset_block_changes (); + allocate_reg_info (FIRST_PSEUDO_REGISTER, true, true); + + /* The "this" pointer is stored at 4(%sp). */ + this_slot = gen_rtx_MEM (Pmode, plus_constant (stack_pointer_rtx, 4)); + + /* Add DELTA to THIS. */ + if (delta != 0) + { + /* Make the offset a legitimate operand for memory addition. */ + offset = GEN_INT (delta); + if ((delta < -8 || delta > 8) + && (TARGET_COLDFIRE || USE_MOVQ (delta))) + { + emit_move_insn (gen_rtx_REG (Pmode, D0_REG), offset); + offset = gen_rtx_REG (Pmode, D0_REG); + } + emit_insn (gen_add3_insn (copy_rtx (this_slot), + copy_rtx (this_slot), offset)); } - else - asm_fprintf (file, (MOTOROLA - ? "\tadd.l %I%wd,4(%Rsp)\n" - : "\taddl %I%wd,%Rsp@(4)\n"), - delta); - - xops[0] = DECL_RTL (function); - - gcc_assert (MEM_P (xops[0]) - && symbolic_operand (XEXP (xops[0], 0), VOIDmode)); - xops[0] = XEXP (xops[0], 0); - - fmt = m68k_symbolic_jump; - if (m68k_symbolic_jump == NULL) - fmt = "move.l %%a1@GOT(%%a5), %%a1\n\tjmp (%%a1)"; - output_asm_insn (fmt, xops); + /* If needed, add *(*THIS + VCALL_OFFSET) to THIS. */ + if (vcall_offset != 0) + { + /* Set the static chain register to *THIS. */ + emit_move_insn (static_chain_rtx, this_slot); + emit_move_insn (static_chain_rtx, gen_rtx_MEM (Pmode, static_chain_rtx)); + + /* Set ADDR to a legitimate address for *THIS + VCALL_OFFSET. */ + addr = plus_constant (static_chain_rtx, vcall_offset); + if (!m68k_legitimate_address_p (Pmode, addr, true)) + { + emit_insn (gen_rtx_SET (VOIDmode, static_chain_rtx, addr)); + addr = static_chain_rtx; + } + + /* Load the offset into %d0 and add it to THIS. */ + emit_move_insn (gen_rtx_REG (Pmode, D0_REG), + gen_rtx_MEM (Pmode, addr)); + emit_insn (gen_add3_insn (copy_rtx (this_slot), + copy_rtx (this_slot), + gen_rtx_REG (Pmode, D0_REG))); + } + + /* Jump to the target function. Use a sibcall if direct jumps are + allowed, otherwise load the address into a register first. */ + mem = DECL_RTL (function); + if (!sibcall_operand (XEXP (mem, 0), VOIDmode)) + { + gcc_assert (flag_pic); + + if (!TARGET_SEP_DATA) + { + /* Use the static chain register as a temporary (call-clobbered) + GOT pointer for this function. We can use the static chain + register because it isn't live on entry to the thunk. */ + REGNO (pic_offset_table_rtx) = STATIC_CHAIN_REGNUM; + emit_insn (gen_load_got (pic_offset_table_rtx)); + } + legitimize_pic_address (XEXP (mem, 0), Pmode, static_chain_rtx); + mem = replace_equiv_address (mem, static_chain_rtx); + } + insn = emit_call_insn (gen_sibcall (mem, const0_rtx)); + SIBLING_CALL_P (insn) = 1; + + /* Run just enough of rest_of_compilation. */ + insn = get_insns (); + split_all_insns_noflow (); + final_start_function (insn, file, 1); + final (insn, file, 1); + final_end_function (); + + /* Clean up the vars set above. */ + reload_completed = 0; + no_new_pseudos = 0; + + /* Restore the original PIC register. */ + if (flag_pic) + REGNO (pic_offset_table_rtx) = PIC_REG; } /* Worker function for TARGET_STRUCT_VALUE_RTX. */ ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 56/63] ColdFire multilibs and --with-arch 2007-01-10 12:13 ` [ColdFire 55/63] Add support for vcall_offset thunks Richard Sandiford @ 2007-01-10 12:15 ` Richard Sandiford 2007-01-10 12:17 ` [ColdFire 57/63] Automatically generate SYSROOT_SUFFIX on uClinux Richard Sandiford 2007-01-16 18:14 ` [ColdFire 55/63] Add support for vcall_offset thunks Jeffrey Law 1 sibling, 1 reply; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 12:15 UTC (permalink / raw) To: gcc-patches This patch adds a full set of ColdFire multilibs to m68k-aout, m68k-coff and m68k-elf. In general, ColdFire code is only link-compatible if it uses the same ISA and extension units (MAC, EMAC, etc.) These configurations now have quite a few different multilibs. Many users will be interested only in the non-ColdFire libraries, while others will only be interested in the ColdFire ones. The patch therefore adds a --with-arch=m68k configuration option to restrict the multilibs to non-ColdFire targets, and a --with-arch=cf configuration to restrict multilibs to ColdFire targets. The full set of multilibs are still built when no --with-arch argument is passed. The patch does a similar thing for m68k-uclinux, but it restricts the multilibs to 68020 and to targets with no MMU. The rest will generally use full linux instead. The patch doesn't change the full set of RTEMS multilibs because RTEMS already selects a subset of the available ColdFire targets. However, the --with-arch option can be used to restrict the RTEMS multilibs in the same way as the other configurations. GNU/Linux, NetBSD and OpenBSD do not build architecture multilibs. However, --with-arch=cf and --with-arch=m68k can still be used to choose between the default m68k -mcpu option and the default ColdFire -mcpu option. Much of the complication in the code is in making all -march, -mcpu and -m68* options work. m68k multilibs are built with -m68* options so that users with older binutils (or non-GNU assemblers) do not need to change assemblers. ColdFire multilibs are built with -mcpu. Richard gcc/ 200x-xx-xx Nathan Sidwell <nathan@codesourcery.com> Richard Sandiford <richard@codesourcery.com> * config.gcc (m68010-*-netbsdelf*, m68k*-*-netbsdelf*) (m68k*-*-openbsd*, m68k-*-linux*): Set default_cf_cpu. (m68k-*-aout*, m68k-*-coff*, m68k-*-uclinux*, m68k-*-rtems*): Add m68k/t-mlib to tmake_file. (m68020-*-elf*, m68k-*-elf*): Likewise. Add t-m68kbare as well. (m68k*-*-*): Use --with-arch to pick a default for --with-cpu. (m680[012]0-*-*, m68k*-*-*): Add support for --with-arch. Allow it to be cf or m68k. Set m68k_arch_family. If that variable is not empty, add t-$m68k_arch_family to tmake_file. Add t-mlibs to tmake_file. * doc/install.texi: Document --with-arch=m68k and --with-arch=cf. * config/m68k/t-cf: New file. * config/m68k/t-m68k: Likewise. * config/m68k/t-mlibs: Likewise. * config/m68k/t-m68kbare (MULTILIB_OPTIONS, MULTILIB_DIRNAMES) (MULTILIB_MATCHES, MULTILIB_EXCEPTIONS): Delete. (M68K_MLIB_DIRNAMES, M68K_MLIB_OPTIONS): Define. * config/m68k/t-m68kelf (MULTILIB_OPTIONS, MULTILIB_DIRNAMES) (MULTILIB_MATCHES, MULTILIB_EXCEPTIONS, LIBGCC, INSTALL_LIBGCC): Delete. * config/m68k/t-openbsd (MULTILIB_OPTIONS, LIBGCC): Delete. (INSTALL_LIBGCC): Delete. (M68K_MLIB_DIRNAMES, M68K_MLIB_OPTIONS): Define. * config/m68k/t-rtems (MULTILIB_OPTIONS, MULTILIB_DIRNAMES) (MULTILIB_MATCHES, MULTILIB_EXCEPTIONS): Delete. (M68K_MLIB_CPU): Define. * config/m68k/t-uclinux (MULTILIB_OPTIONS, MULTILIB_DIRNAMES) (MULTILIB_MATCHES, MULTILIB_EXCEPTIONS): Delete. (M68K_MLIB_CPU, M68K_MLIB_OPTIONS, M68K_MLIB_DIRNAMES): Define. Index: gcc/config.gcc =================================================================== --- gcc/config.gcc 2007-01-10 08:33:02.000000000 +0000 +++ gcc/config.gcc 2007-01-10 09:08:43.000000000 +0000 @@ -1479,30 +1479,35 @@ m68hc12-*-*|m6812-*-*) ;; m68k-*-aout*) default_m68k_cpu=68020 - tmake_file="m68k/t-floatlib m68k/t-m68kbare" + default_cf_cpu=5206 + tmake_file="m68k/t-floatlib m68k/t-m68kbare m68k/t-mlibs" tm_file="${tm_file} m68k/m68k-none.h m68k/m68kemb.h m68k/m68k-aout.h libgloss.h" ;; m68k-*-coff*) default_m68k_cpu=68020 - tmake_file="m68k/t-floatlib m68k/t-m68kbare" + default_cf_cpu=5206 + tmake_file="m68k/t-floatlib m68k/t-m68kbare m68k/t-mlibs" tm_defines="${tm_defines} MOTOROLA=1 USE_GAS" tm_file="${tm_file} m68k/m68k-none.h m68k/m68kemb.h dbxcoff.h m68k/coff.h dbx.h" use_fixproto=yes ;; m68020-*-elf* | m68k-*-elf*) default_m68k_cpu=68020 + default_cf_cpu=5206 tm_file="${tm_file} m68k/m68k-none.h m68k/m68kelf.h dbxelf.h elfos.h m68k/m68kemb.h m68k/m68020-elf.h" tm_defines="${tm_defines} MOTOROLA=1 USE_GAS" - tmake_file="m68k/t-floatlib m68k/t-m68kelf" + tmake_file="m68k/t-floatlib m68k/t-m68kbare m68k/t-m68kelf m68k/t-mlibs" extra_parts="crtbegin.o crtend.o" ;; m68010-*-netbsdelf* | m68k*-*-netbsdelf*) default_m68k_cpu=68020 + default_cf_cpu=5485 tm_file="${tm_file} dbxelf.h elfos.h netbsd.h netbsd-elf.h m68k/netbsd-elf.h" tm_defines="${tm_defines} MOTOROLA=1 USE_GAS" ;; m68k*-*-openbsd*) default_m68k_cpu=68020 + default_cf_cpu=5485 # needed to unconfuse gdb tm_defines="${tm_defines} OBSD_OLD_GAS" tm_file="${tm_file} openbsd.h m68k/openbsd.h" @@ -1512,16 +1517,18 @@ m68k*-*-openbsd*) ;; m68k-*-uclinux*) # Motorola m68k/ColdFire running uClinux with uClibc default_m68k_cpu=68020 + default_cf_cpu=5206 tm_file="${tm_file} dbxelf.h elfos.h svr4.h linux.h flat.h m68k/linux.h m68k/uclinux.h" tm_defines="${tm_defines} MOTOROLA=1 USE_GAS UCLIBC_DEFAULT=1" extra_options="${extra_options} linux.opt" - tmake_file="m68k/t-floatlib m68k/t-uclinux" + tmake_file="m68k/t-floatlib m68k/t-uclinux m68k/t-mlibs" use_fixproto=no ;; m68k-*-linux*) # Motorola m68k's running GNU/Linux # with ELF format using glibc 2 # aka the GNU/Linux C library 6. default_m68k_cpu=68020 + default_cf_cpu=5475 tm_file="${tm_file} dbxelf.h elfos.h svr4.h linux.h m68k/linux.h" extra_options="${extra_options} m68k/ieee.opt" tm_defines="${tm_defines} MOTOROLA=1 USE_GAS" @@ -1533,7 +1540,8 @@ m68k-*-linux*) # Motorola m68k's runnin ;; m68k-*-rtems*) default_m68k_cpu=68020 - tmake_file="m68k/t-floatlib m68k/t-m68kbare m68k/t-crtstuff t-rtems m68k/t-rtems" + default_cf_cpu=5206 + tmake_file="m68k/t-floatlib m68k/t-m68kbare m68k/t-crtstuff t-rtems m68k/t-rtems m68k/t-mlibs" tm_file="${tm_file} m68k/m68k-none.h m68k/m68kelf.h dbxelf.h elfos.h m68k/m68kemb.h m68k/m68020-elf.h m68k/rtemself.h rtems.h" tm_defines="${tm_defines} MOTOROLA=1 USE_GAS" extra_parts="crtbegin.o crtend.o" @@ -2630,7 +2638,14 @@ if test x$with_cpu = x ; then with_cpu=`echo ${target} | sed 's/-.*$//'` ;; m68k*-*-*) - with_cpu=m${default_m68k_cpu} + case "$with_arch" in + "cf") + with_cpu=${default_cf_cpu} + ;; + "" | "m68k") + with_cpu=m${default_m68k_cpu} + ;; + esac ;; sparc*-*-*) with_cpu="`echo ${target} | sed 's/-.*$//'`" @@ -2781,7 +2796,16 @@ case "${target}" in ;; m680[012]0-*-* | m68k*-*-*) - supported_defaults="cpu" + supported_defaults="arch cpu" + case "$with_arch" in + "" | "m68k"| "cf") + m68k_arch_family="$with_arch" + ;; + *) + echo "Invalid --with-arch=$with_arch" 1>&2 + exit 1 + ;; + esac # We always have a $with_cpu setting here. case "$with_cpu" in @@ -3067,6 +3091,9 @@ case ${target} in m680[012]0-*-* | m68k*-*-*) target_cpu_default2=$m68k_cpu_ident + if [ x"$m68k_arch_family" != x ]; then + tmake_file="m68k/t-$m68k_arch_family $tmake_file" + fi ;; mips*-*-*) Index: gcc/doc/install.texi =================================================================== --- gcc/doc/install.texi 2007-01-10 09:03:56.000000000 +0000 +++ gcc/doc/install.texi 2007-01-10 10:06:12.000000000 +0000 @@ -3390,9 +3390,24 @@ applications. There are no standard Uni <hr /> @end html @heading @anchor{m68k-*-*}m68k-*-* -You can specify a default target using @option{--with-cpu=@var{target}}. -This @var{target} can either be a @option{-mcpu} argument or one of the -following values: @samp{m68000}, @samp{m68010}, @samp{m68020}, @samp{m68030}, +By default, @samp{m68k-*-aout}, @samp{m68k-*-coff*}, +@samp{m68k-*-elf*}, @samp{m68k-*-rtems} and @samp{m68k-*-uclinux} +build libraries for both M680x0 and ColdFire processors. If you only +need the M680x0 libraries, you can omit the ColdFire ones by passing +@option{--with-arch=m68k} to @command{configure}. Alternatively, you +can omit the M680x0 libraries by passing @option{--with-arch=cf} to +@command{configure}. These targets default to 5206 code when +configured with @option{--with-arch=cf} and 68020 code otherwise. + +The @samp{m68k-*-linux-gnu}, @samp{m68k-*-netbsd} and +@samp{m68k-*-openbsd} targets also support the @option{--with-arch} +option. They will generate ColdFire CFV4e code when configured with +@option{--with-arch=cf} and 68020 code otherwise. + +You can override the default processors listed above by configuring +with @option{--with-cpu=@var{target}}. This @var{target} can either +be a @option{-mcpu} argument or one of the following values: +@samp{m68000}, @samp{m68010}, @samp{m68020}, @samp{m68030}, @samp{m68040}, @samp{m68060}, @samp{m68020-40} and @samp{m68020-60}. @heading @anchor{m68k-hp-hpux}m68k-hp-hpux Index: gcc/config/m68k/t-cf =================================================================== --- /dev/null 2007-01-10 05:44:58.552097000 +0000 +++ gcc/config/m68k/t-cf 2007-01-10 08:33:02.000000000 +0000 @@ -0,0 +1,4 @@ +# Select only ColdFire-specific CPUs. + +M68K_MLIB_CPU += && (CPU ~ "^mcf") +M68K_ARCH := cf Index: gcc/config/m68k/t-m68k =================================================================== --- /dev/null 2007-01-10 05:44:58.552097000 +0000 +++ gcc/config/m68k/t-m68k 2007-01-10 08:33:02.000000000 +0000 @@ -0,0 +1,4 @@ +# Select only 680x0-specific CPUs. + +M68K_MLIB_CPU += && (CPU !~ "^mcf") +M68K_ARCH := m68k Index: gcc/config/m68k/t-mlibs =================================================================== --- /dev/null 2007-01-10 05:44:58.552097000 +0000 +++ gcc/config/m68k/t-mlibs 2007-01-10 08:33:02.000000000 +0000 @@ -0,0 +1,97 @@ +# multilibs -*- mode:Makefile -*- + +# An awk command to extract lines from the m68k-devices.def file that +# match $1 and then print the string defined by $2. Leading and +# trailing whitespace is removed. $1 & $2 can make use of +# CPU -- the cpu identifier (has leading 'm'/'mcf') +# FLAGS -- the cpu capability flags +# CPU_NAME -- the cpu name (has no leading m/mcf) +# MLIB -- the multilib cpu name (no leading m/mcf) +# This is intended to be used as $(call M68K_AWK,predicate,string) +M68K_AWK = $(strip $(shell $(AWK) 'BEGIN { FS="[ \t]*[,()][ \t]*"; ORS=" " }; \ + /^M68K_DEVICE/ { CPU=$$3; FLAGS=$$8; \ + CPU_NAME=substr($$2,2,length($$2)-2); \ + MLIB=substr($$5,2,length($$5)-2); \ + if ($1) print $2 }' $(srcdir)/config/m68k/m68k-devices.def)) + +# Add a multilib for each distinct architecture. M68K_MLIB_CPU, if defined, +# adds additional restrictions. +M68K_MLIB_CPUS := $(call M68K_AWK,\ + (CPU_NAME == MLIB) $(M68K_MLIB_CPU), \ + "m"MLIB) + +# Make the default cpu the default multilib. +M68K_MLIB_DEFAULT := $(call M68K_AWK, CPU == "$(target_cpu_default)", MLIB) + +ifeq ($(filter m$(M68K_MLIB_DEFAULT),$(M68K_MLIB_CPUS)),) +$(error Error default cpu '$(target_cpu_default)' is not in multilib set '$(M68K_MLIB_CPUS)') +endif + +# Sed arguments that convert mcpu=* arguments into canonical forms. +# We want to use the legacy m68* options instead of the new -mcpu=68* +# options when compiling multilibs because the former are recognised +# by older binutils. +CANONICALIZE_OPTIONS = -e 's|mcpu=68|m68|g' -e 's|mcpu=cpu32|mcpu32|g' + +MULTILIB_DIRNAMES := $(filter-out m$(M68K_MLIB_DEFAULT),$(M68K_MLIB_CPUS)) +MULTILIB_OPTIONS := $(shell echo $(MULTILIB_DIRNAMES:m%=mcpu=%) \ + | sed -e 's| |/|g' $(CANONICALIZE_OPTIONS)) + +# Add subtarget specific options & dirs. +MULTILIB_DIRNAMES += $(M68K_MLIB_DIRNAMES) +MULTILIB_OPTIONS += $(M68K_MLIB_OPTIONS) + +MULTILIB_MATCHES := + +ifneq ($(M68K_ARCH),cf) +# Map the new-style options to the legacy m68k ones. +MULTILIB_MATCHES += m68000=mcpu?68000 m68000=march?68000 m68000=mc68000 \ + m68000=m68302 \ + m68020=mcpu?68020 m68020=march?68020 m68020=mc68020 \ + m68030=mcpu?68030 m68030=march?68030 \ + m68040=mcpu?68040 m68040=march?68040 \ + m68060=mcpu?68060 m68060=march?68060 \ + mcpu32=mcpu?cpu32 mcpu32=march?cpu32 mcpu32=m68332 +endif + +ifneq ($(M68K_ARCH),m68k) +# Map the legacy ColdFire options to the new ones. +MULTILIB_MATCHES += mcpu?5206=m5200 mcpu?5206e=m5206e mcpu?5208=m528x \ + mcpu?5307=m5300 mcpu?5307=m5307 \ + mcpu?5407=m5400 mcpu?5407=m5407 \ + mcpu?5475=mcfv4e +# Map -march=* options to the representative -mcpu=* option. +MULTILIB_MATCHES += mcpu?5206e=march?isaa mcpu?5208=march?isaaplus \ + mcpu?5407=march?isab +endif + +# Match non-representative -mcpu options to their representative option. +MULTILIB_MATCHES += \ + $(call M68K_AWK, \ + (CPU_NAME != MLIB) $(M68K_MLIB_CPU), \ + (match(MLIB, "^68") || MLIB == "cpu32" \ + ? "m"MLIB"=mcpu?"CPU_NAME \ + : "mcpu?"MLIB"=mcpu?"CPU_NAME)) + +MULTILIB_EXCEPTIONS := + +ifeq ($(firstword $(M68K_MLIB_OPTIONS)),msoft-float) +# Exclude soft-float multilibs for targets that default to soft-float anyway. +MULTILIB_EXCEPTIONS += $(call M68K_AWK,\ + (CPU_NAME == MLIB) $(M68K_MLIB_CPU) \ + && (((CPU ~ "^mcf") && !match(FLAGS, "FL_CF_FPU")) \ + || CPU == "cpu32" \ + || CPU == "m68000"), \ + "mcpu="MLIB"/msoft-float*") +endif + +# Remove the default CPU from the explicit exceptions. +MULTILIB_EXCEPTIONS := \ + $(patsubst mcpu=$(M68K_MLIB_DEFAULT)/%,%,$(MULTILIB_EXCEPTIONS)) + +# Convert all options to canonical form. +MULTILIB_EXCEPTIONS := $(shell echo $(MULTILIB_EXCEPTIONS) | \ + sed $(CANONICALIZE_OPTIONS)) + +LIBGCC = stmp-multilib +INSTALL_LIBGCC = install-multilib Index: gcc/config/m68k/t-m68kbare =================================================================== --- gcc/config/m68k/t-m68kbare 2007-01-10 08:33:02.000000000 +0000 +++ gcc/config/m68k/t-m68kbare 2007-01-10 08:33:02.000000000 +0000 @@ -1,7 +1,4 @@ -MULTILIB_OPTIONS = m68000/m68020/m5200/mcpu32/m68040/m68060 m68881/msoft-float -MULTILIB_DIRNAMES = -MULTILIB_MATCHES = m68000=mc68000 m68000=m68302 mcpu32=m68332 m68020=mc68020 -MULTILIB_EXCEPTIONS = m68000/msoft-float m5200/m68881 m5200/msoft-float mcpu32/m68881 mcpu32/msoft-float m68040/m68881 m68060/m68881 +# Add soft-float multilibs. +M68K_MLIB_DIRNAMES += softfp +M68K_MLIB_OPTIONS += msoft-float -LIBGCC = stmp-multilib -INSTALL_LIBGCC = install-multilib Index: gcc/config/m68k/t-m68kelf =================================================================== --- gcc/config/m68k/t-m68kelf 2007-01-10 08:33:02.000000000 +0000 +++ gcc/config/m68k/t-m68kelf 2007-01-10 08:33:02.000000000 +0000 @@ -1,15 +1,3 @@ -MULTILIB_OPTIONS = m68000/m68020/m5200/m5206e/m528x/m5307/m5407/mcfv4e/mcpu32/m68040/m68060 m68881/msoft-float -MULTILIB_DIRNAMES = -MULTILIB_MATCHES = m68000=mc68000 m68000=m68302 mcpu32=m68332 m68020=mc68020 m5206e=m5272 -MULTILIB_EXCEPTIONS = m68000/msoft-float m5200/m68881 m5200/msoft-float \ - m5206e/m68881 m5206e/msoft-float m528x/m68881 m528x/msoft-float \ - m5307/m68881 m5307/msoft-float m5407/m68881 m5407/msoft-float \ - mcpu32/m68881 mcpu32/msoft-float m68040/m68881 m68040/msoft-float \ - m68060/m68881 m68060/msoft-float \ - mcfv4e/msoft-float mcfv4e/m68881 -LIBGCC = stmp-multilib -INSTALL_LIBGCC = install-multilib - # from ../t-svr4 EXTRA_MULTILIB_PARTS=crtbegin.o crtend.o # no pic for now Index: gcc/config/m68k/t-openbsd =================================================================== --- gcc/config/m68k/t-openbsd 2007-01-10 08:32:52.000000000 +0000 +++ gcc/config/m68k/t-openbsd 2007-01-10 08:33:02.000000000 +0000 @@ -1,5 +1,4 @@ # gdb gets confused if pic code is linked with non pic # We cope by building all variants of libgcc. -MULTILIB_OPTIONS = fpic/fPIC -LIBGCC = stmp-multilib -INSTALL_LIBGCC = install-multilib +M68K_MLIB_OPTIONS += fpic/fPIC +M68K_MLIB_DIRNAMES += fpic fPIC Index: gcc/config/m68k/t-rtems =================================================================== --- gcc/config/m68k/t-rtems 2007-01-10 08:32:52.000000000 +0000 +++ gcc/config/m68k/t-rtems 2007-01-10 08:33:02.000000000 +0000 @@ -1,7 +1,4 @@ # Custom multilibs for RTEMS - -MULTILIB_OPTIONS = m68000/m68020/m5200/mcpu32/m68030/m68040/m68060 m68881/msoft-float -MULTILIB_DIRNAMES = -MULTILIB_MATCHES = m68000=mc68000 m68000=m68302 mcpu32=m68332 m68020=mc68020 m68030=mc68030 -MULTILIB_MATCHES += m5200=m528x -MULTILIB_EXCEPTIONS = m68000/msoft-float m5200/m68881 m5200/msoft-float mcpu32/m68881 mcpu32/msoft-float m68040/m68881 m68060/m68881 +M68K_MLIB_CPU += && (match(MLIB, "^68") \ + || MLIB == "cpu32" \ + || MLIB == "5206") Index: gcc/config/m68k/t-uclinux =================================================================== --- gcc/config/m68k/t-uclinux 2007-01-10 08:33:02.000000000 +0000 +++ gcc/config/m68k/t-uclinux 2007-01-10 09:03:25.000000000 +0000 @@ -1,10 +1,9 @@ # crti and crtn are provided by uClibc. EXTRA_MULTILIB_PARTS=crtbegin.o crtend.o -MULTILIB_OPTIONS = m68000/m5200/m5206e/m528x/m5307/m5407/mcpu32 msep-data/mid-shared-library -MULTILIB_DIRNAMES = -MULTILIB_MATCHES = m68000=mc68000 m68000=m68302 mcpu32=m68332 m5206e=m5272 -MULTILIB_EXCEPTIONS = m68000/msep-data* m68000/mid-shared-library* msep-data* mid-shared-library* +# Only include multilibs for the 68020 and for CPUs without an MMU. +M68K_MLIB_CPU += && (MLIB == "68020" || !match(FLAGS, "FL_MMU")) -LIBGCC = stmp-multilib -INSTALL_LIBGCC = install-multilib +# Add multilibs for execute-in-place and shared-library code. +M68K_MLIB_OPTIONS += msep-data/mid-shared-library +M68K_MLIB_DIRNAMES += msep-data mid-shared-library ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 57/63] Automatically generate SYSROOT_SUFFIX on uClinux 2007-01-10 12:15 ` [ColdFire 56/63] ColdFire multilibs and --with-arch Richard Sandiford @ 2007-01-10 12:17 ` Richard Sandiford 2007-01-10 12:19 ` [ColdFire 58/63] XFAIL mul-subnormal-single-1 for ColdFire FPUs Richard Sandiford 0 siblings, 1 reply; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 12:17 UTC (permalink / raw) To: gcc-patches Another multilib-related patch. uClinux builds many multilibs, and some of them are not link-compatible with each other. Some users will only want to build a sysroot for one of the supported targets, but others (particularly distributors) will want sysroots for several. This patch tries to support both needs by defining SYSROOT_SUFFIX_SPEC automatically. A new script, print-sysroot-suffix.sh, takes a list of multilibs as argument and sees which of those multilibs have a corresponding subdirectory in the build-time sysroot. If the subdirectory exists, the associated multilibs will use it. For simplicity, the script assumes that if the multilib directory for option A exists, and the multilib directory for option B exists, the subdirectory for the combination of A and B also exists. The spec string would be prohibitively long if we had to enumerate every permutation. Richard gcc/ * configure.ac: Allow tm_file to contain build-directory files. * configure: Regenerate. * config.gcc (m68k-*-uclinux*): Add ./sysroot-suffix.h to tm_file. * config/m68k/t-uclinux (sysroot-suffix.h): New target. * config/m68k/print-sysroot-suffix.sh: New file. Index: gcc/configure.ac =================================================================== --- gcc/configure.ac 2007-01-09 13:18:10.000000000 +0000 +++ gcc/configure.ac 2007-01-09 15:02:28.000000000 +0000 @@ -1664,6 +1664,11 @@ tm_file_list="options.h" tm_include_list="options.h" for f in $tm_file; do case $f in + ./* ) + f=`echo $f | sed 's/^..//'` + tm_file_list="${tm_file_list} $f" + tm_include_list="${tm_include_list} $f" + ;; defaults.h ) tm_file_list="${tm_file_list} \$(srcdir)/$f" tm_include_list="${tm_include_list} $f" Index: gcc/configure =================================================================== --- gcc/configure 2007-01-09 13:18:10.000000000 +0000 +++ gcc/configure 2007-01-09 15:02:28.000000000 +0000 @@ -13086,6 +13086,11 @@ tm_file_list="options.h" tm_include_list="options.h" for f in $tm_file; do case $f in + ./* ) + f=`echo $f | sed 's/^..//'` + tm_file_list="${tm_file_list} $f" + tm_include_list="${tm_include_list} $f" + ;; defaults.h ) tm_file_list="${tm_file_list} \$(srcdir)/$f" tm_include_list="${tm_include_list} $f" Index: gcc/config.gcc =================================================================== --- gcc/config.gcc 2007-01-09 15:02:26.000000000 +0000 +++ gcc/config.gcc 2007-01-09 15:02:28.000000000 +0000 @@ -1511,7 +1511,7 @@ m68k*-*-openbsd*) m68k-*-uclinux*) # Motorola m68k/ColdFire running uClinux with uClibc default_m68k_cpu=68020 default_cf_cpu=5206 - tm_file="${tm_file} dbxelf.h elfos.h svr4.h linux.h flat.h m68k/linux.h m68k/uclinux.h" + tm_file="${tm_file} dbxelf.h elfos.h svr4.h linux.h flat.h m68k/linux.h m68k/uclinux.h ./sysroot-suffix.h" tm_defines="${tm_defines} MOTOROLA=1 USE_GAS UCLIBC_DEFAULT=1" extra_options="${extra_options} linux.opt" tmake_file="m68k/t-floatlib m68k/t-uclinux" Index: gcc/config/m68k/t-uclinux =================================================================== --- gcc/config/m68k/t-uclinux 2007-01-09 15:02:26.000000000 +0000 +++ gcc/config/m68k/t-uclinux 2007-01-09 15:02:28.000000000 +0000 @@ -7,3 +7,10 @@ M68K_MLIB_CPU += && (MLIB == "68020" || # add some library style multilibs M68K_MLIB_OPTIONS += msep-data/mid-shared-library M68K_MLIB_DIRNAMES += msep-data mid-shared-library + +# This rule uses MULTILIB_MATCHES to generate a definition of +# SYSROOT_SUFFIX_SPEC. +sysroot-suffix.h: $(srcdir)/config/m68k/print-sysroot-suffix.sh + $(SHELL) $(srcdir)/config/m68k/print-sysroot-suffix.sh \ + "$(SYSTEM_HEADER_DIR)/../.." "$(MULTILIB_MATCHES)" \ + "$(MULTILIB_OPTIONS)" > $@ Index: gcc/config/m68k/print-sysroot-suffix.sh =================================================================== --- /dev/null 2007-01-09 03:39:34.548096750 +0000 +++ gcc/config/m68k/print-sysroot-suffix.sh 2007-01-09 15:02:28.000000000 +0000 @@ -0,0 +1,82 @@ +#!/bin/sh +# Copyright (C) 2006 Free Software Foundation, Inc. +# This file is part of GCC. + +# GCC is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2, or (at your option) +# any later version. + +# GCC is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. + +# You should have received a copy of the GNU General Public License +# along with GCC; see the file COPYING. If not, write to +# the Free Software Foundation, 51 Franklin Street, Fifth Floor, +# Boston MA 02110-1301, USA. + +# This script takes the following arguments: +# +# - the target sysroot +# - the value of $(MULTILIB_MATCHES) +# - the value of $(MULTILIB_OPTIONS) +# +# It uses these arguments to construct a definition of SYSROOT_SUFFIX_SPEC, +# which it prints to the standard output. For each multilib directory FOO, +# the script checks whether $sysroot has a subdirectory FOO, and if so will +# use /FOO for all compatible command-line options. It will not add a +# suffix for /FOO's options otherwise. These suffixes are concatenated, +# with one subspec for each space-separated entry in $(MULTILIB_OPTIONS). +set -e +sysroot=$1 +matches=$2 +options=$3 + +# For each multilib option OPT, add to $substs a sed command of the +# form "-e 's/OPT/OPT/'". +substs="" +for option in `echo "$options" | tr '/' ' '` +do + substs="$substs -e 's/$option/$option/g'" +done + +# For each ALIAS=CANONICAL entry in $MULTILIB_MATCHES, look for sed +# arguments in $substs of the form "-e 's/CANONICAL/.../'". Replace +# such entries with "-e 's/CANONICAL/ALIAS|.../'". Both the ALIAS and +# CANONICAL parts of $MULTILIB_MATCHES use '?' to stand for '='. +# +# After this loop, a command of the form "echo FOO | eval sed $substs" +# will replace a canonical option FOO with a %{...}-style spec pattern. +for match in $matches +do + canonical=`echo "$match" | sed -e 's/=.*//' -e 's/?/=/g'` + alias=`echo "$match" | sed -e 's/.*=//' -e 's/?/=/g'` + substs=`echo "$substs" | sed -e "s,s/$canonical/,&$alias|,"` +done + +# Build up the final SYSROOT_SUFFIX_SPEC in $spec. +spec= +for combo in $options +do + # See which option alternatives in $combo have their own sysroot + # directory. Create a subspec of the form "%{PAT1:/DIR1;...;PATn:DIRn}" + # from each such option OPTi, where DIRi is the directory associated + # with OPTi and PATi is the result of passing OPTi through $substs. + subspec= + for option in `echo "$combo" | tr '/' ' '` + do + dir=`echo "$option" | sed 's/cpu=//'` + if test -d "$sysroot/$dir"; then + test -z "$subspec" || subspec="$subspec;" + subspec="$subspec"`echo "$option" | eval sed $substs`":/$dir" + fi + done + # Concatenate all the subspecs. + test -z "$subspec" || spec="$spec%{$subspec}" +done +if test -n "$spec"; then + echo "#undef SYSROOT_SUFFIX_SPEC" + echo "#define SYSROOT_SUFFIX_SPEC \"$spec\"" +fi ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 58/63] XFAIL mul-subnormal-single-1 for ColdFire FPUs 2007-01-10 12:17 ` [ColdFire 57/63] Automatically generate SYSROOT_SUFFIX on uClinux Richard Sandiford @ 2007-01-10 12:19 ` Richard Sandiford 2007-01-10 12:21 ` [ColdFire 59/63] compat-related testsuite fixes for uClinux Richard Sandiford 0 siblings, 1 reply; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 12:19 UTC (permalink / raw) To: gcc-patches gcc.c-torture/execute/ieee/mul-subnormal-single-1.c tests subnormal support, which must be handled by software emulation when using a ColdFire FPU. The linux kernel does not yet support this. Richard gcc/testsuite/ * lib/target-supports.exp (check_effective_target_coldfire_fpu): New procedure. * gcc.c-torture/execute/ieee/mul-subnormal-single-1.x: XFAIL on m68k targets if check_effective_target_coldfire_fpu returns true. Index: gcc/testsuite/lib/target-supports.exp =================================================================== --- gcc/testsuite/lib/target-supports.exp 2007-01-09 13:18:10.000000000 +0000 +++ gcc/testsuite/lib/target-supports.exp 2007-01-09 15:02:31.000000000 +0000 @@ -1989,6 +1989,16 @@ proc check_effective_target_sync_char_sh return $et_sync_char_short_saved } +# Return 1 if the target uses a ColdFire FPU. + +proc check_effective_target_coldfire_fpu { } { + return [check_no_compiler_messages coldfire_fpu assembly { + #ifndef __mcffpu__ + #error FOO + #endif + }] +} + # Return 1 if the target matches the effective target 'arg', 0 otherwise. # This can be used with any check_* proc that takes no argument and # returns only 1 or 0. It could be used with check_* procs that take Index: gcc/testsuite/gcc.c-torture/execute/ieee/mul-subnormal-single-1.x =================================================================== --- gcc/testsuite/gcc.c-torture/execute/ieee/mul-subnormal-single-1.x 2007-01-09 13:18:10.000000000 +0000 +++ gcc/testsuite/gcc.c-torture/execute/ieee/mul-subnormal-single-1.x 2007-01-09 15:02:31.000000000 +0000 @@ -3,4 +3,9 @@ if [istarget "mips-sgi-irix6*"] { # isn't expected to work for n32 and n64 on MIPS IV targets. return 1 } +if {[istarget "m68k-*-linux-gnu*"] && [check_effective_target_coldfire_fpu]} { + # ColdFire FPUs require software handling of subnormals. Linux does + # not yet have this. + set torture_execute_xfail "m68k-*-linux-gnu*" +} return 0 ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 59/63] compat-related testsuite fixes for uClinux 2007-01-10 12:19 ` [ColdFire 58/63] XFAIL mul-subnormal-single-1 for ColdFire FPUs Richard Sandiford @ 2007-01-10 12:21 ` Richard Sandiford 2007-01-10 12:22 ` [ColdFire 60/63] Tweak the memset() builtin tests Richard Sandiford 0 siblings, 1 reply; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 12:21 UTC (permalink / raw) To: gcc-patches When using uClinux flat executables, the data segment is only guaranteed to have MAX_SHARED_LIBS * sizeof (intptr_t) bytes of alignment. The default value of MAX_SHARED_LIBS is 1 if shared libraries are not enabled, but an alignment of sizeof (intptr_t) is often too low to run the gcc testsuites. It's better to run the testsuites with shared libraries enabled, in which case the usual value of MAX_SHARED_LIBS is 4. The maximum data alignment is therefore 16 on most targets. struct-layout-1 has two types that need more alignment than that, namely v16sf and u16sf. The tests are written in such a way that it doesn't matter whether these types are really 64-byte quantities, so this patch defines them to v4sf and u4sf on uClinux targets. This is similar to the special measures taken for __m64 on non-x86 targets and for all vector types if SKIP_ATTRIBUTE. I've equated them to smaller vector types rather than "int" so that the tests do remain vector tests. Richard gcc/testsuite/ * gcc.dg/compat/struct-layout-1.h (v16sf): Define to v4sf on uClinux targets. (u16sf): Likewise u4sf. * g++.dg/compat/struct-layout-1.h: Likewise. Index: gcc/testsuite/gcc.dg/compat/struct-layout-1.h =================================================================== --- gcc/testsuite/gcc.dg/compat/struct-layout-1.h 2007-01-09 13:18:10.000000000 +0000 +++ gcc/testsuite/gcc.dg/compat/struct-layout-1.h 2007-01-09 15:02:31.000000000 +0000 @@ -57,6 +57,11 @@ typedef int __m128; typedef int __m64; typedef int __m128; #endif +#if defined (__uClinux__) +/* The maximum achievable alignment on uClinux is usually 16 bytes. */ +#define v16sf v4sf +#define u16sf u4sf +#endif #define FLDS_MAX 32 extern struct Info Index: gcc/testsuite/g++.dg/compat/struct-layout-1.h =================================================================== --- gcc/testsuite/g++.dg/compat/struct-layout-1.h 2007-01-09 13:18:10.000000000 +0000 +++ gcc/testsuite/g++.dg/compat/struct-layout-1.h 2007-01-09 15:02:31.000000000 +0000 @@ -57,6 +57,11 @@ typedef int __m128; typedef int __m64; typedef int __m128; #endif +#if defined (__uClinux__) +/* The maximum achievable alignment on uClinux is usually 16 bytes. */ +#define v16sf v4sf +#define u16sf u4sf +#endif #define FLDS_MAX 32 extern struct Info ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 60/63] Tweak the memset() builtin tests 2007-01-10 12:21 ` [ColdFire 59/63] compat-related testsuite fixes for uClinux Richard Sandiford @ 2007-01-10 12:22 ` Richard Sandiford 2007-01-10 12:24 ` [ColdFire 61/63] Fix vsnprintf() tests on uClibc Richard Sandiford 0 siblings, 1 reply; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 12:22 UTC (permalink / raw) To: gcc-patches Some ColdFire start-up routines use memset() to clear bss. This caused a failure in the builtins testsuite because the memset() replacement checks the bss inside_main variable before doing anything (i.e. when inside_main is still uninitialised). The simplest fix is to do the memset() regardless of whether inside_main is set, then abort afterwards if appropriate. The memops-asm-lib.c part makes the same change in the copying code for consistency. Richard 200x-xx-xx Nathan Sidwell <nathan@codesourcery.com> gcc/testsuite/ * gcc.c-torture/execute/builtins/memops-asm-lib.c: Do the copy or set before checking whether it was allowed. * gcc.c-torture/execute/builtins/lib/memset.c: Do the memset before checking inside_main. Index: gcc/testsuite/gcc.c-torture/execute/builtins/memops-asm-lib.c =================================================================== --- gcc/testsuite/gcc.c-torture/execute/builtins/memops-asm-lib.c 2007-01-09 13:18:10.000000000 +0000 +++ gcc/testsuite/gcc.c-torture/execute/builtins/memops-asm-lib.c 2007-01-09 15:02:32.000000000 +0000 @@ -51,27 +51,29 @@ my_bzero (void *d, size_t n) void * memcpy (void *d, const void *s, size_t n) { + void *result = my_memcpy (d, s, n); TEST_ABORT; - return my_memcpy (d, s, n); + return result; } void bcopy (const void *s, void *d, size_t n) { - TEST_ABORT; my_bcopy (s, d, n); + TEST_ABORT; } void * memset (void *d, int c, size_t n) { + void *result = my_memset (d, c, n); TEST_ABORT; - return my_memset (d, c, n); + return result; } void bzero (void *d, size_t n) { - TEST_ABORT; my_bzero (d, n); + TEST_ABORT; } Index: gcc/testsuite/gcc.c-torture/execute/builtins/lib/memset.c =================================================================== --- gcc/testsuite/gcc.c-torture/execute/builtins/lib/memset.c 2007-01-09 13:18:10.000000000 +0000 +++ gcc/testsuite/gcc.c-torture/execute/builtins/lib/memset.c 2007-01-09 15:02:32.000000000 +0000 @@ -4,15 +4,16 @@ extern void abort (void); void * memset (void *dst, int c, __SIZE_TYPE__ n) { + while (n-- != 0) + n[(char *) dst] = c; + /* Single-byte memsets should be done inline when optimisation - is enabled. */ + is enabled. Do this after the copy in case we're being called to + initialize bss. */ #ifdef __OPTIMIZE__ if (inside_main && n < 2) abort (); #endif - while (n-- != 0) - n[(char *) dst] = c; - return dst; } ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 61/63] Fix vsnprintf() tests on uClibc 2007-01-10 12:22 ` [ColdFire 60/63] Tweak the memset() builtin tests Richard Sandiford @ 2007-01-10 12:24 ` Richard Sandiford 2007-01-10 12:25 ` [ColdFire 62/63] Tighten check in 20030125-1.x Richard Sandiford 0 siblings, 1 reply; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 12:24 UTC (permalink / raw) To: gcc-patches uClibc's implementation of vsprintf calls vsnprintf. This caused another failure in the buitlins testsuite, because the checking version of vsnprintf calls vsprintf, leading to mutual recursion. It also means that __*printf_chk functions were unexpectedly calling the checking version of vsnprintf. This patch simply disabled vsnprintf checking on uClibc targets. Richard gcc/testsuite/ * gcc.c-torture/execute/builtins/lib/chk.c: Include <sys/types.h>. (vsnprintf): Don't define for uClibc targets. Index: gcc/testsuite/gcc.c-torture/execute/builtins/lib/chk.c =================================================================== --- gcc/testsuite/gcc.c-torture/execute/builtins/lib/chk.c 2007-01-09 13:18:10.000000000 +0000 +++ gcc/testsuite/gcc.c-torture/execute/builtins/lib/chk.c 2007-01-09 15:02:32.000000000 +0000 @@ -1,4 +1,5 @@ #include <stdarg.h> +#include <sys/types.h> extern void abort (void); @@ -448,6 +449,8 @@ snprintf (char *str, __SIZE_TYPE__ len, return ret; } +/* uClibc's vsprintf calls vsnprintf. */ +#ifndef __UCLIBC__ int vsnprintf (char *str, __SIZE_TYPE__ len, const char *fmt, va_list ap) { @@ -470,3 +473,4 @@ vsnprintf (char *str, __SIZE_TYPE__ len, } return ret; } +#endif ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 62/63] Tighten check in 20030125-1.x 2007-01-10 12:24 ` [ColdFire 61/63] Fix vsnprintf() tests on uClibc Richard Sandiford @ 2007-01-10 12:25 ` Richard Sandiford 2007-01-10 12:27 ` [ColdFire 63/63] libstdc++ testsuite fixes for uClibc Richard Sandiford 0 siblings, 1 reply; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 12:25 UTC (permalink / raw) To: gcc-patches gcc.c-torture/execute/20030125-1.x is restricted to "*linux*" targets as it requires a fullish set of C99 functions. However, it's really the C library that matters, not the kernel. glibc implements the required functions but uClibc doesn't. This patch therefore changes the target to *-linux*. Neither that nor *-linux-gnu* are enough on their own though, because some *-linux-gnu* configurations support uClibc multilibs. The patch therefore adds a new check_effective_target_uclibc function too. Richard gcc/testsuite/ * gcc.c-torture/execute/20030125-1.x: Return 1 for uClibc targets. * lib/target-supports.exp (check_effective_target_uclibc): New function. Index: gcc/testsuite/gcc.c-torture/execute/20030125-1.x =================================================================== --- gcc/testsuite/gcc.c-torture/execute/20030125-1.x 2007-01-09 13:18:10.000000000 +0000 +++ gcc/testsuite/gcc.c-torture/execute/20030125-1.x 2007-01-09 15:02:33.000000000 +0000 @@ -1,3 +1,4 @@ -# Only Linux does inlclude all c99 functions at the moment. -if { ! [istarget "*linux*"] } { return 1 } +# Only glibc includes all c99 functions at the moment. +if { ! [istarget "*-linux*"] } { return 1 } +if { [check_effective_target_uclibc] } { return 1 } return 0 Index: gcc/testsuite/lib/target-supports.exp =================================================================== --- gcc/testsuite/lib/target-supports.exp 2007-01-09 15:02:31.000000000 +0000 +++ gcc/testsuite/lib/target-supports.exp 2007-01-09 15:02:33.000000000 +0000 @@ -1999,6 +1999,17 @@ proc check_effective_target_coldfire_fpu }] } +# Return true if this is a uClibc target. + +proc check_effective_target_uclibc {} { + return [check_no_compiler_messages uclibc object { + #include <features.h> + #if !defined (__UCLIBC__) + #error FOO + #endif + }] +} + # Return 1 if the target matches the effective target 'arg', 0 otherwise. # This can be used with any check_* proc that takes no argument and # returns only 1 or 0. It could be used with check_* procs that take ^ permalink raw reply [flat|nested] 280+ messages in thread
* [ColdFire 63/63] libstdc++ testsuite fixes for uClibc 2007-01-10 12:25 ` [ColdFire 62/63] Tighten check in 20030125-1.x Richard Sandiford @ 2007-01-10 12:27 ` Richard Sandiford 2007-01-10 14:52 ` Paolo Bonzini 2007-01-10 17:31 ` Benjamin Kosnik 0 siblings, 2 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 12:27 UTC (permalink / raw) To: gcc-patches; +Cc: libstdc++ uClibc's string-to-floating-point conversion routines are not accurate to within 0.5 ULP; this is a deliberate size vs. accuracy trade-off. Also, its wcsftime is currently a dummy function that always returns 0. These two problems cause some failures in the libstdc++ testsuite. The patch below adds separate check_effective_target routines for the two problems, partly to make the XFAILs more self-documenting, and partly because the routines may need to depend on the precise uClibc version in future. At the moment though, they're just wrappers for check_effective_target_uclibc. Richard gcc/testsuite/ * lib/target-supports.exp (check_effective_target_uclibc_lax_strtofp) (check_effective_target_uclibc_dummy_wcsftime): New functions. libstdc++-v3/testsuite/ * 22_locale/time_put/put/wchar_t/1.cc: XFAIL if uclibc_dummy_wcsftime. * 22_locale/time_put/put/wchar_t/5.cc: Likewise. * 22_locale/time_put/put/wchar_t/9.cc: Likewise. * 22_locale/time_put/put/wchar_t/10.cc: Likewise. * 22_locale/num_get/get/wchar_t/2.cc: XFAIL if uclibc_lax_strtofp. * 22_locale/num_get/get/char/2.cc: Likewise. * 27_io/basic_istream/extractors_arithmetic/wchar_t/12.cc: Likewise. * 27_io/basic_istream/extractors_arithmetic/wchar_t/09.cc: Likewise. * 27_io/basic_istream/extractors_arithmetic/char/12.cc: Likewise. * 27_io/basic_istream/extractors_arithmetic/char/09.cc: Likewise. * 27_io/basic_ostream/inserters_arithmetic/wchar_t/6.cc: Likewise. * 27_io/basic_ostream/inserters_arithmetic/char/6.cc: Likewise. * 26_numerics/cmath/c99_classification_macros_c++.cc: XFAIL for uClibc. * 26_numerics/cmath/c99_classification_macros_c.cc: Likewise. Index: gcc/testsuite/lib/target-supports.exp =================================================================== --- gcc/testsuite/lib/target-supports.exp 2007-01-09 15:02:33.000000000 +0000 +++ gcc/testsuite/lib/target-supports.exp 2007-01-09 15:02:33.000000000 +0000 @@ -2010,6 +2010,25 @@ proc check_effective_target_uclibc {} { }] } +# Return 1 if +# (a) this is a uClibc target; and +# (b) an error of a few ULP is expected in string to floating-point +# conversion functions; and +# (c) overflow is not always detected correctly by those functions. + +proc check_effective_target_uclibc_lax_strtofp {} { + # By default, assume that all uClibc targets suffer from this. + return [check_effective_target_uclibc] +} + +# Return 1 if this is a uClibc target for which wcsftime is a dummy +# function that always returns 0. + +proc check_effective_target_uclibc_dummy_wcsftime {} { + # By default, assume that all uClibc targets suffer from this. + return [check_effective_target_uclibc] +} + # Return 1 if the target matches the effective target 'arg', 0 otherwise. # This can be used with any check_* proc that takes no argument and # returns only 1 or 0. It could be used with check_* procs that take Index: libstdc++-v3/testsuite/22_locale/time_put/put/wchar_t/1.cc =================================================================== --- libstdc++-v3/testsuite/22_locale/time_put/put/wchar_t/1.cc 2007-01-09 13:18:10.000000000 +0000 +++ libstdc++-v3/testsuite/22_locale/time_put/put/wchar_t/1.cc 2007-01-09 15:02:33.000000000 +0000 @@ -20,6 +20,8 @@ // 22.2.5.3.1 time_put members +// { dg-do run { xfail uclibc_dummy_wcsftime } } + #include <locale> #include <sstream> #include <testsuite_hooks.h> Index: libstdc++-v3/testsuite/22_locale/time_put/put/wchar_t/5.cc =================================================================== --- libstdc++-v3/testsuite/22_locale/time_put/put/wchar_t/5.cc 2007-01-09 13:18:10.000000000 +0000 +++ libstdc++-v3/testsuite/22_locale/time_put/put/wchar_t/5.cc 2007-01-09 15:02:33.000000000 +0000 @@ -20,6 +20,8 @@ // 22.2.5.3.1 time_put members +// { dg-do run { xfail uclibc_dummy_wcsftime } } + #include <locale> #include <sstream> #include <testsuite_hooks.h> Index: libstdc++-v3/testsuite/22_locale/time_put/put/wchar_t/9.cc =================================================================== --- libstdc++-v3/testsuite/22_locale/time_put/put/wchar_t/9.cc 2007-01-09 13:18:10.000000000 +0000 +++ libstdc++-v3/testsuite/22_locale/time_put/put/wchar_t/9.cc 2007-01-09 15:02:33.000000000 +0000 @@ -20,6 +20,8 @@ // 22.2.5.3.1 time_put members +// { dg-do run { xfail uclibc_dummy_wcsftime } } + #include <locale> #include <sstream> #include <testsuite_hooks.h> Index: libstdc++-v3/testsuite/22_locale/time_put/put/wchar_t/10.cc =================================================================== --- libstdc++-v3/testsuite/22_locale/time_put/put/wchar_t/10.cc 2007-01-09 13:18:10.000000000 +0000 +++ libstdc++-v3/testsuite/22_locale/time_put/put/wchar_t/10.cc 2007-01-09 15:02:33.000000000 +0000 @@ -20,6 +20,8 @@ // 22.2.5.3.1 time_put members +// { dg-do run { xfail uclibc_dummy_wcsftime } } + #include <locale> #include <sstream> #include <testsuite_hooks.h> Index: libstdc++-v3/testsuite/22_locale/num_get/get/wchar_t/2.cc =================================================================== --- libstdc++-v3/testsuite/22_locale/num_get/get/wchar_t/2.cc 2007-01-09 13:18:09.000000000 +0000 +++ libstdc++-v3/testsuite/22_locale/num_get/get/wchar_t/2.cc 2007-01-09 15:02:33.000000000 +0000 @@ -20,6 +20,8 @@ // 22.2.2.1.1 num_get members +// { dg-do run { xfail uclibc_lax_strtofp } } + #include <locale> #include <sstream> #include <testsuite_hooks.h> Index: libstdc++-v3/testsuite/22_locale/num_get/get/char/2.cc =================================================================== --- libstdc++-v3/testsuite/22_locale/num_get/get/char/2.cc 2007-01-09 13:18:10.000000000 +0000 +++ libstdc++-v3/testsuite/22_locale/num_get/get/char/2.cc 2007-01-09 15:02:33.000000000 +0000 @@ -20,6 +20,8 @@ // 22.2.2.1.1 num_get members +// { dg-do run { xfail uclibc_lax_strtofp } } + #include <locale> #include <sstream> #include <testsuite_hooks.h> Index: libstdc++-v3/testsuite/27_io/basic_istream/extractors_arithmetic/wchar_t/12.cc =================================================================== --- libstdc++-v3/testsuite/27_io/basic_istream/extractors_arithmetic/wchar_t/12.cc 2007-01-09 13:18:10.000000000 +0000 +++ libstdc++-v3/testsuite/27_io/basic_istream/extractors_arithmetic/wchar_t/12.cc 2007-01-09 15:02:33.000000000 +0000 @@ -21,7 +21,7 @@ // XXX This test fails on sparc-solaris2 because of a bug in libc // XXX sscanf for very long input. See: // XXX http://gcc.gnu.org/ml/gcc/2002-12/msg01422.html -// { dg-do run { xfail sparc*-*-solaris2* } } +// { dg-do run { xfail { { sparc*-*-solaris2* } || uclibc_lax_strtofp } } } #include <istream> #include <sstream> Index: libstdc++-v3/testsuite/27_io/basic_istream/extractors_arithmetic/wchar_t/09.cc =================================================================== --- libstdc++-v3/testsuite/27_io/basic_istream/extractors_arithmetic/wchar_t/09.cc 2007-01-09 13:18:10.000000000 +0000 +++ libstdc++-v3/testsuite/27_io/basic_istream/extractors_arithmetic/wchar_t/09.cc 2007-01-09 15:02:33.000000000 +0000 @@ -18,6 +18,8 @@ // 27.6.1.2.2 arithmetic extractors +// { dg-do run { xfail uclibc_lax_strtofp } } + #include <istream> #include <sstream> #include <locale> Index: libstdc++-v3/testsuite/27_io/basic_istream/extractors_arithmetic/char/12.cc =================================================================== --- libstdc++-v3/testsuite/27_io/basic_istream/extractors_arithmetic/char/12.cc 2007-01-09 13:18:10.000000000 +0000 +++ libstdc++-v3/testsuite/27_io/basic_istream/extractors_arithmetic/char/12.cc 2007-01-09 15:02:33.000000000 +0000 @@ -23,7 +23,7 @@ // XXX This test fails on sparc-solaris2 because of a bug in libc // XXX sscanf for very long input. See: // XXX http://gcc.gnu.org/ml/gcc/2002-12/msg01422.html -// { dg-do run { xfail sparc*-*-solaris2* } } +// { dg-do run { xfail { { sparc*-*-solaris2* } || uclibc_lax_strtofp } } } #include <istream> #include <sstream> Index: libstdc++-v3/testsuite/27_io/basic_istream/extractors_arithmetic/char/09.cc =================================================================== --- libstdc++-v3/testsuite/27_io/basic_istream/extractors_arithmetic/char/09.cc 2007-01-09 13:18:10.000000000 +0000 +++ libstdc++-v3/testsuite/27_io/basic_istream/extractors_arithmetic/char/09.cc 2007-01-09 15:02:33.000000000 +0000 @@ -20,6 +20,8 @@ // 27.6.1.2.2 arithmetic extractors +// { dg-do run { xfail uclibc_lax_strtofp } } + #include <istream> #include <sstream> #include <locale> Index: libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/wchar_t/6.cc =================================================================== --- libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/wchar_t/6.cc 2007-01-09 13:18:10.000000000 +0000 +++ libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/wchar_t/6.cc 2007-01-09 15:02:33.000000000 +0000 @@ -16,6 +16,8 @@ // Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, // USA. +// { dg-do run { xfail uclibc_lax_strtofp } } + #include <cmath> // for abs #include <cfloat> // for DBL_EPSILON #include <sstream> Index: libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/6.cc =================================================================== --- libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/6.cc 2007-01-09 13:18:10.000000000 +0000 +++ libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/6.cc 2007-01-09 15:02:33.000000000 +0000 @@ -19,6 +19,8 @@ // Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, // USA. +// { dg-do run { xfail uclibc_lax_strtofp } } + #include <cmath> // for abs #include <cfloat> // for DBL_EPSILON #include <sstream> Index: libstdc++-v3/testsuite/26_numerics/cmath/c99_classification_macros_c++.cc =================================================================== --- libstdc++-v3/testsuite/26_numerics/cmath/c99_classification_macros_c++.cc 2007-01-09 13:18:10.000000000 +0000 +++ libstdc++-v3/testsuite/26_numerics/cmath/c99_classification_macros_c++.cc 2007-01-09 15:02:33.000000000 +0000 @@ -27,7 +27,8 @@ // invalidate any other reasons why the executable file might be covered by // the GNU General Public License. -// { dg-do compile } +// { dg-do compile { xfail uclibc } } +// { dg-excess-errors "" { target uclibc } } #include <cmath> Index: libstdc++-v3/testsuite/26_numerics/cmath/c99_classification_macros_c.cc =================================================================== --- libstdc++-v3/testsuite/26_numerics/cmath/c99_classification_macros_c.cc 2007-01-09 13:18:10.000000000 +0000 +++ libstdc++-v3/testsuite/26_numerics/cmath/c99_classification_macros_c.cc 2007-01-09 15:02:33.000000000 +0000 @@ -27,8 +27,8 @@ // invalidate any other reasons why the executable file might be covered by // the GNU General Public License. -// { dg-do compile { xfail *-*-linux* *-*-darwin* } } -// { dg-excess-errors "" { target *-*-linux* *-*-darwin* } } +// { dg-do compile { xfail { { *-*-linux* *-*-darwin* } || uclibc } } } +// { dg-excess-errors "" { target { { *-*-linux* *-*-darwin* } || uclibc } } } #include <math.h> ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 63/63] libstdc++ testsuite fixes for uClibc 2007-01-10 12:27 ` [ColdFire 63/63] libstdc++ testsuite fixes for uClibc Richard Sandiford @ 2007-01-10 14:52 ` Paolo Bonzini 2007-01-10 15:12 ` Richard Sandiford 2007-01-10 17:31 ` Benjamin Kosnik 1 sibling, 1 reply; 280+ messages in thread From: Paolo Bonzini @ 2007-01-10 14:52 UTC (permalink / raw) To: gcc-patches, libstdc++, richard > gcc/testsuite/ > * lib/target-supports.exp (check_effective_target_uclibc_lax_strtofp) > (check_effective_target_uclibc_dummy_wcsftime): New functions. Why _uclibc_ in the name? Paolo ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 63/63] libstdc++ testsuite fixes for uClibc 2007-01-10 14:52 ` Paolo Bonzini @ 2007-01-10 15:12 ` Richard Sandiford 2007-01-10 15:18 ` Paolo Bonzini 0 siblings, 1 reply; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 15:12 UTC (permalink / raw) To: Paolo Bonzini; +Cc: gcc-patches, libstdc++ Paolo Bonzini <paolo.bonzini@lu.unisi.ch> writes: >> gcc/testsuite/ >> * lib/target-supports.exp (check_effective_target_uclibc_lax_strtofp) >> (check_effective_target_uclibc_dummy_wcsftime): New functions. > > Why _uclibc_ in the name? I can remove it you want. I wanted it particularly in the first case because the XFAILs are based specifically on what the uClibc implementation gets right or wrong. Some other lax implementation might get overflow right but still not be accurate to 0.5 ULP, for example. Or maybe it would be inaccurate in different ways, and get different sets of values right and wrong. The names were really meant to mean "I'm using a version of uClibc which has ...". (_uclibc_with_, or something). Richard ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 63/63] libstdc++ testsuite fixes for uClibc 2007-01-10 15:12 ` Richard Sandiford @ 2007-01-10 15:18 ` Paolo Bonzini 0 siblings, 0 replies; 280+ messages in thread From: Paolo Bonzini @ 2007-01-10 15:18 UTC (permalink / raw) To: Paolo Bonzini, gcc-patches, libstdc++, richard Richard Sandiford wrote: > Paolo Bonzini <paolo.bonzini@lu.unisi.ch> writes: >>> gcc/testsuite/ >>> * lib/target-supports.exp (check_effective_target_uclibc_lax_strtofp) >>> (check_effective_target_uclibc_dummy_wcsftime): New functions. >> Why _uclibc_ in the name? > > I can remove it you want. I just wondered. Anyway I'm not a maintainer and they will make the call. :-) Paolo ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 63/63] libstdc++ testsuite fixes for uClibc 2007-01-10 12:27 ` [ColdFire 63/63] libstdc++ testsuite fixes for uClibc Richard Sandiford 2007-01-10 14:52 ` Paolo Bonzini @ 2007-01-10 17:31 ` Benjamin Kosnik 1 sibling, 0 replies; 280+ messages in thread From: Benjamin Kosnik @ 2007-01-10 17:31 UTC (permalink / raw) To: gcc-patches, libstdc++, richard This is fine. I'd also prefer nixing the _uclibc_ part of the check_effective_target_* functions, since in the past we've not used configure to indite. -benjamin ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 55/63] Add support for vcall_offset thunks 2007-01-10 12:13 ` [ColdFire 55/63] Add support for vcall_offset thunks Richard Sandiford 2007-01-10 12:15 ` [ColdFire 56/63] ColdFire multilibs and --with-arch Richard Sandiford @ 2007-01-16 18:14 ` Jeffrey Law 1 sibling, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-01-16 18:14 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches On Wed, 2007-01-10 at 12:13 +0000, Richard Sandiford wrote: > This patch makes m68k_output_mi_thunk hnour vcall_offset. It was > easier to do this in rtl than by writing assembly directly, so the > patch converts the entire function to use rtl. > > The main difficulty is in using a call-clobbered PIC register for the > duration of the thunk. I've used the same PIC_OFFSET_TABLE_REGNUM trick > that x86 and MIPS use. > > Richard > > > gcc/ > * config/m68k/m68k.h (PIC_OFFSET_TABLE_REGNUM): Use the REGNO > of pic_offset_table_rtx if reload_completed. > (CONDITIONAL_REGISTER_USAGE): Use PIC_REG instead of > PIC_OFFSET_TABLE_REGNUM. > * config/m68k/m68k.c (TARGET_ASM_CAN_OUTPUT_MI_THUNK): Always > return true. > (m68k_save_reg): Use PIC_REG instead of PIC_OFFSET_TABLE_REGNO. > (m68k_output_mi_thunk): Rewrite to use RTL. Honor vcall_offset. OK. Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 54/63] Define PREFERRED_STACK_BOUNDARY 2007-01-10 12:11 ` [ColdFire 54/63] Define PREFERRED_STACK_BOUNDARY Richard Sandiford 2007-01-10 12:13 ` [ColdFire 55/63] Add support for vcall_offset thunks Richard Sandiford @ 2007-01-10 18:00 ` Jeffrey Law 2007-01-16 2:35 ` Roman Zippel 2 siblings, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-01-10 18:00 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches On Wed, 2007-01-10 at 12:10 +0000, Richard Sandiford wrote: > The m68k ABI does not guarantee that the stack is aligned to 4 bytes, > but for efficiency reasons, the ColdFire targets strongly prefer it to be. > This patch defines PREFERRED_STACK_BOUNDARY accordingly. > > Richard > > > gcc/ > * config/m68k/m68k.h (PREFERRED_STACK_BOUNDARY): Define to 32 > for ColdFire targets. OK. Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 54/63] Define PREFERRED_STACK_BOUNDARY 2007-01-10 12:11 ` [ColdFire 54/63] Define PREFERRED_STACK_BOUNDARY Richard Sandiford 2007-01-10 12:13 ` [ColdFire 55/63] Add support for vcall_offset thunks Richard Sandiford 2007-01-10 18:00 ` [ColdFire 54/63] Define PREFERRED_STACK_BOUNDARY Jeffrey Law @ 2007-01-16 2:35 ` Roman Zippel 2007-01-16 17:08 ` Jeffrey Law 2 siblings, 1 reply; 280+ messages in thread From: Roman Zippel @ 2007-01-16 2:35 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches Hi, On Wed, 10 Jan 2007, Richard Sandiford wrote: > Index: gcc/config/m68k/m68k.h > =================================================================== > --- gcc/config/m68k/m68k.h 2007-01-09 15:02:24.000000000 +0000 > +++ gcc/config/m68k/m68k.h 2007-01-09 15:02:25.000000000 +0000 > @@ -284,6 +284,8 @@ #define PARM_BOUNDARY (TARGET_SHORT ? 16 > #define STACK_BOUNDARY 16 > #define FUNCTION_BOUNDARY 16 > #define EMPTY_FIELD_BOUNDARY 16 > +/* ColdFire strongly prefers a 32-bit aligned stack. */ > +#define PREFERRED_STACK_BOUNDARY (TARGET_COLDFIRE ? 32 : 16) > > /* No data type wants to be aligned rounder than this. > Most published ABIs say that ints should be aligned on 16 bit Actually this could be done unconditionally. I did this also for Debian, as I got tired of all the broken software... An alternative might be to redefine unconditionally it just for Linux. bye, Roman ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 54/63] Define PREFERRED_STACK_BOUNDARY 2007-01-16 2:35 ` Roman Zippel @ 2007-01-16 17:08 ` Jeffrey Law 0 siblings, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-01-16 17:08 UTC (permalink / raw) To: Roman Zippel; +Cc: Richard Sandiford, gcc-patches On Tue, 2007-01-16 at 03:34 +0100, Roman Zippel wrote: > Hi, > > On Wed, 10 Jan 2007, Richard Sandiford wrote: > > > Index: gcc/config/m68k/m68k.h > > =================================================================== > > --- gcc/config/m68k/m68k.h 2007-01-09 15:02:24.000000000 +0000 > > +++ gcc/config/m68k/m68k.h 2007-01-09 15:02:25.000000000 +0000 > > @@ -284,6 +284,8 @@ #define PARM_BOUNDARY (TARGET_SHORT ? 16 > > #define STACK_BOUNDARY 16 > > #define FUNCTION_BOUNDARY 16 > > #define EMPTY_FIELD_BOUNDARY 16 > > +/* ColdFire strongly prefers a 32-bit aligned stack. */ > > +#define PREFERRED_STACK_BOUNDARY (TARGET_COLDFIRE ? 32 : 16) > > > > /* No data type wants to be aligned rounder than this. > > Most published ABIs say that ints should be aligned on 16 bit > > Actually this could be done unconditionally. I did this also for Debian, > as I got tired of all the broken software... > An alternative might be to redefine unconditionally it just for Linux. I probably wouldn't do it unconditionally -- there may easily be some m68k targets that get some benefit from aligned stacks, but the benefit is marginal and not worth the increase in stack space. It's not something I feel that strongly about though... jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 53/63] Static chain fixes 2007-01-10 12:10 ` [ColdFire 53/63] Static chain fixes Richard Sandiford 2007-01-10 12:11 ` [ColdFire 54/63] Define PREFERRED_STACK_BOUNDARY Richard Sandiford @ 2007-01-10 19:19 ` Jeffrey Law 2007-01-10 21:32 ` Paul Brook 2007-01-10 21:33 ` Richard Sandiford 1 sibling, 2 replies; 280+ messages in thread From: Jeffrey Law @ 2007-01-10 19:19 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches On Wed, 2007-01-10 at 12:10 +0000, Richard Sandiford wrote: > m68k*-elf targets use %a0 as both the incoming structure return address > _and_ the static chain pointer. This causes a conflict if a nested function > returns a structure. > > This patch moves the static chain register to %a1 for these targets only. > It also generalises the template code to cope with static chain registers > other than %a0. > > Richard > > > gcc/ > 200x-xx-xx Nathan Sidwell <nathan@codesourcery.com> > Richard Sandiford <richard@codesourcery.com> > > * config/m68k/m68k.h (M68K_STATIC_CHAIN_REG_NAME): New macro. > (INITIALIZE_TRAMPOLINE): Use STATIC_CHAIN_REGNUM. > (__transfer_from_trampoline): Use M68K_STATIC_CHAIN_REG_NAME. > * config/m68k/m68kelf.h (STATIC_CHAIN_REGNUM): Override. > (M68K_STATIC_CHAIN_REG_NAME): Likewise. > * config/m68k/netbsd-elf.h (M68K_STATIC_CHAIN_REG_NAME): Likewise. > > gcc/testsuite/ > 200x-xx-xx Nathan Sidwell <nathan@codesourcery.com> > > * gcc.c-torture/execute/nestfunc-7.c: New. Isn't this an ABI change? If so it needs to be documented at the least so that users of the m68k elf port aren't caught by surprise. I think we've now got two ABI changes to document for the next release of GCC. If we don't have a good place to document them we should make it now. jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 53/63] Static chain fixes 2007-01-10 19:19 ` [ColdFire 53/63] Static chain fixes Jeffrey Law @ 2007-01-10 21:32 ` Paul Brook 2007-01-10 21:48 ` Jeffrey Law 2007-01-10 21:33 ` Richard Sandiford 1 sibling, 1 reply; 280+ messages in thread From: Paul Brook @ 2007-01-10 21:32 UTC (permalink / raw) To: gcc-patches, law; +Cc: Richard Sandiford > > * config/m68k/m68k.h (M68K_STATIC_CHAIN_REG_NAME): New macro. > > (INITIALIZE_TRAMPOLINE): Use STATIC_CHAIN_REGNUM. > > (__transfer_from_trampoline): Use M68K_STATIC_CHAIN_REG_NAME. > > * config/m68k/m68kelf.h (STATIC_CHAIN_REGNUM): Override. > > (M68K_STATIC_CHAIN_REG_NAME): Likewise. > > * config/m68k/netbsd-elf.h (M68K_STATIC_CHAIN_REG_NAME): Likewise. > > > > gcc/testsuite/ > > 200x-xx-xx Nathan Sidwell <nathan@codesourcery.com> > > > > * gcc.c-torture/execute/nestfunc-7.c: New. > > Isn't this an ABI change? If so it needs to be documented at the least > so that users of the m68k elf port aren't caught by surprise. I thought STATIC_CHAIN_REGNUM was an internal implementation detail. It's a private interface between the trampoline and the nested function, and never escapes to the outside world. Paul ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 53/63] Static chain fixes 2007-01-10 21:32 ` Paul Brook @ 2007-01-10 21:48 ` Jeffrey Law 2007-01-10 21:54 ` Andrew Pinski 0 siblings, 1 reply; 280+ messages in thread From: Jeffrey Law @ 2007-01-10 21:48 UTC (permalink / raw) To: Paul Brook; +Cc: gcc-patches, Richard Sandiford On Wed, 2007-01-10 at 21:32 +0000, Paul Brook wrote: > > > * config/m68k/m68k.h (M68K_STATIC_CHAIN_REG_NAME): New macro. > > > (INITIALIZE_TRAMPOLINE): Use STATIC_CHAIN_REGNUM. > > > (__transfer_from_trampoline): Use M68K_STATIC_CHAIN_REG_NAME. > > > * config/m68k/m68kelf.h (STATIC_CHAIN_REGNUM): Override. > > > (M68K_STATIC_CHAIN_REG_NAME): Likewise. > > > * config/m68k/netbsd-elf.h (M68K_STATIC_CHAIN_REG_NAME): Likewise. > > > > > > gcc/testsuite/ > > > 200x-xx-xx Nathan Sidwell <nathan@codesourcery.com> > > > > > > * gcc.c-torture/execute/nestfunc-7.c: New. > > > > Isn't this an ABI change? If so it needs to be documented at the least > > so that users of the m68k elf port aren't caught by surprise. > > I thought STATIC_CHAIN_REGNUM was an internal implementation detail. > It's a private interface between the trampoline and the nested function, and > never escapes to the outside world. Doesn't the caller need to tell the callee where to find stacked variables? It seems to me the caller and callee need to agree on that location. jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 53/63] Static chain fixes 2007-01-10 21:48 ` Jeffrey Law @ 2007-01-10 21:54 ` Andrew Pinski 2007-01-10 22:06 ` Jeffrey Law 0 siblings, 1 reply; 280+ messages in thread From: Andrew Pinski @ 2007-01-10 21:54 UTC (permalink / raw) To: law; +Cc: Paul Brook, gcc-patches, Richard Sandiford > > On Wed, 2007-01-10 at 21:32 +0000, Paul Brook wrote: > > > > * config/m68k/m68k.h (M68K_STATIC_CHAIN_REG_NAME): New macro. > > > > (INITIALIZE_TRAMPOLINE): Use STATIC_CHAIN_REGNUM. > > > > (__transfer_from_trampoline): Use M68K_STATIC_CHAIN_REG_NAME. > > > > * config/m68k/m68kelf.h (STATIC_CHAIN_REGNUM): Override. > > > > (M68K_STATIC_CHAIN_REG_NAME): Likewise. > > > > * config/m68k/netbsd-elf.h (M68K_STATIC_CHAIN_REG_NAME): Likewise. > > > > > > > > gcc/testsuite/ > > > > 200x-xx-xx Nathan Sidwell <nathan@codesourcery.com> > > > > > > > > * gcc.c-torture/execute/nestfunc-7.c: New. > > > > > > Isn't this an ABI change? If so it needs to be documented at the least > > > so that users of the m68k elf port aren't caught by surprise. > > > > I thought STATIC_CHAIN_REGNUM was an internal implementation detail. > > It's a private interface between the trampoline and the nested function, and > > never escapes to the outside world. > Doesn't the caller need to tell the callee where to find stacked > variables? It seems to me the caller and callee need to agree on > that location. Yes they have to agree but the only place which uses static chain are for nested functions and nested functions are always local to the TU. -- Pinski ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 53/63] Static chain fixes 2007-01-10 21:54 ` Andrew Pinski @ 2007-01-10 22:06 ` Jeffrey Law 2007-01-10 22:09 ` Daniel Jacobowitz 2007-01-10 22:11 ` Richard Sandiford 0 siblings, 2 replies; 280+ messages in thread From: Jeffrey Law @ 2007-01-10 22:06 UTC (permalink / raw) To: Andrew Pinski; +Cc: Paul Brook, gcc-patches, Richard Sandiford On Wed, 2007-01-10 at 16:51 -0500, Andrew Pinski wrote: > > > > On Wed, 2007-01-10 at 21:32 +0000, Paul Brook wrote: > > > > > * config/m68k/m68k.h (M68K_STATIC_CHAIN_REG_NAME): New macro. > > > > > (INITIALIZE_TRAMPOLINE): Use STATIC_CHAIN_REGNUM. > > > > > (__transfer_from_trampoline): Use M68K_STATIC_CHAIN_REG_NAME. > > > > > * config/m68k/m68kelf.h (STATIC_CHAIN_REGNUM): Override. > > > > > (M68K_STATIC_CHAIN_REG_NAME): Likewise. > > > > > * config/m68k/netbsd-elf.h (M68K_STATIC_CHAIN_REG_NAME): Likewise. > > > > > > > > > > gcc/testsuite/ > > > > > 200x-xx-xx Nathan Sidwell <nathan@codesourcery.com> > > > > > > > > > > * gcc.c-torture/execute/nestfunc-7.c: New. > > > > > > > > Isn't this an ABI change? If so it needs to be documented at the least > > > > so that users of the m68k elf port aren't caught by surprise. > > > > > > I thought STATIC_CHAIN_REGNUM was an internal implementation detail. > > > It's a private interface between the trampoline and the nested function, and > > > never escapes to the outside world. > > Doesn't the caller need to tell the callee where to find stacked > > variables? It seems to me the caller and callee need to agree on > > that location. > > Yes they have to agree but the only place which uses static chain are for > nested functions and nested functions are always local to the TU. Why must they be local. Take the address of a nested function and pass it as an argument to a function outside the current translation unit. IIRC the only restriction we've made on calling nested functions is that the container function must still be on the dynamic call stack. jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 53/63] Static chain fixes 2007-01-10 22:06 ` Jeffrey Law @ 2007-01-10 22:09 ` Daniel Jacobowitz 2007-01-11 17:17 ` Jeffrey Law 2007-01-10 22:11 ` Richard Sandiford 1 sibling, 1 reply; 280+ messages in thread From: Daniel Jacobowitz @ 2007-01-10 22:09 UTC (permalink / raw) To: Jeffrey Law; +Cc: Andrew Pinski, Paul Brook, gcc-patches, Richard Sandiford On Wed, Jan 10, 2007 at 03:05:37PM -0700, Jeffrey Law wrote: > Why must they be local. > > Take the address of a nested function and pass it as an argument to a > function outside the current translation unit. IIRC the only > restriction we've made on calling nested functions is that the > container function must still be on the dynamic call stack. But the function that took the address is responsible for creating the trampoline which sets up the static chain register, isn't it? We don't pass the static chain out to anything else. -- Daniel Jacobowitz CodeSourcery ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 53/63] Static chain fixes 2007-01-10 22:09 ` Daniel Jacobowitz @ 2007-01-11 17:17 ` Jeffrey Law 0 siblings, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-01-11 17:17 UTC (permalink / raw) To: Daniel Jacobowitz Cc: Andrew Pinski, Paul Brook, gcc-patches, Richard Sandiford On Wed, 2007-01-10 at 17:09 -0500, Daniel Jacobowitz wrote: > On Wed, Jan 10, 2007 at 03:05:37PM -0700, Jeffrey Law wrote: > > Why must they be local. > > > > Take the address of a nested function and pass it as an argument to a > > function outside the current translation unit. IIRC the only > > restriction we've made on calling nested functions is that the > > container function must still be on the dynamic call stack. > > But the function that took the address is responsible for creating the > trampoline which sets up the static chain register, isn't it? We don't > pass the static chain out to anything else. I think you're right for the m68k. So consider my concerns a non-issue. jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 53/63] Static chain fixes 2007-01-10 22:06 ` Jeffrey Law 2007-01-10 22:09 ` Daniel Jacobowitz @ 2007-01-10 22:11 ` Richard Sandiford 1 sibling, 0 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 22:11 UTC (permalink / raw) To: law; +Cc: Andrew Pinski, Paul Brook, gcc-patches Jeffrey Law <law@redhat.com> writes: > On Wed, 2007-01-10 at 16:51 -0500, Andrew Pinski wrote: >> > >> > On Wed, 2007-01-10 at 21:32 +0000, Paul Brook wrote: >> > > > > * config/m68k/m68k.h (M68K_STATIC_CHAIN_REG_NAME): New macro. >> > > > > (INITIALIZE_TRAMPOLINE): Use STATIC_CHAIN_REGNUM. >> > > > > (__transfer_from_trampoline): Use M68K_STATIC_CHAIN_REG_NAME. >> > > > > * config/m68k/m68kelf.h (STATIC_CHAIN_REGNUM): Override. >> > > > > (M68K_STATIC_CHAIN_REG_NAME): Likewise. >> > > > > * config/m68k/netbsd-elf.h (M68K_STATIC_CHAIN_REG_NAME): Likewise. >> > > > > >> > > > > gcc/testsuite/ >> > > > > 200x-xx-xx Nathan Sidwell <nathan@codesourcery.com> >> > > > > >> > > > > * gcc.c-torture/execute/nestfunc-7.c: New. >> > > > >> > > > Isn't this an ABI change? If so it needs to be documented at the least >> > > > so that users of the m68k elf port aren't caught by surprise. >> > > >> > > I thought STATIC_CHAIN_REGNUM was an internal implementation detail. >> > > It's a private interface between the trampoline and the nested function, and >> > > never escapes to the outside world. >> > Doesn't the caller need to tell the callee where to find stacked >> > variables? It seems to me the caller and callee need to agree on >> > that location. >> >> Yes they have to agree but the only place which uses static chain are for >> nested functions and nested functions are always local to the TU. > Why must they be local. > > Take the address of a nested function and pass it as an argument to a > function outside the current translation unit. IIRC the only > restriction we've made on calling nested functions is that the > container function must still be on the dynamic call stack. But when we do that, we actually pass the address of a trampoline function, which is just a black box as far as the other translation unit is concerned. That trampoline reads the static chain register from memory (which is also part of the trampoline) and then calls the real function. Richard ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 53/63] Static chain fixes 2007-01-10 19:19 ` [ColdFire 53/63] Static chain fixes Jeffrey Law 2007-01-10 21:32 ` Paul Brook @ 2007-01-10 21:33 ` Richard Sandiford 2007-01-10 21:44 ` Richard Sandiford 2007-01-15 0:19 ` Gerald Pfeifer 1 sibling, 2 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 21:33 UTC (permalink / raw) To: law; +Cc: gcc-patches Jeffrey Law <law@redhat.com> writes: > On Wed, 2007-01-10 at 12:10 +0000, Richard Sandiford wrote: >> m68k*-elf targets use %a0 as both the incoming structure return address >> _and_ the static chain pointer. This causes a conflict if a nested function >> returns a structure. >> >> This patch moves the static chain register to %a1 for these targets only. >> It also generalises the template code to cope with static chain registers >> other than %a0. >> >> Richard >> >> >> gcc/ >> 200x-xx-xx Nathan Sidwell <nathan@codesourcery.com> >> Richard Sandiford <richard@codesourcery.com> >> >> * config/m68k/m68k.h (M68K_STATIC_CHAIN_REG_NAME): New macro. >> (INITIALIZE_TRAMPOLINE): Use STATIC_CHAIN_REGNUM. >> (__transfer_from_trampoline): Use M68K_STATIC_CHAIN_REG_NAME. >> * config/m68k/m68kelf.h (STATIC_CHAIN_REGNUM): Override. >> (M68K_STATIC_CHAIN_REG_NAME): Likewise. >> * config/m68k/netbsd-elf.h (M68K_STATIC_CHAIN_REG_NAME): Likewise. >> >> gcc/testsuite/ >> 200x-xx-xx Nathan Sidwell <nathan@codesourcery.com> >> >> * gcc.c-torture/execute/nestfunc-7.c: New. > Isn't this an ABI change? If so it needs to be documented at the least > so that users of the m68k elf port aren't caught by surprise. Of sorts, although I'm not aware of any actual XFmode emulation code for ColdFire. I suspect most ColdFire users just avoided using long double altogether. This may be my ignorance though. ;) To be honest, I wasn't involved in the discussions that led to this change, but I thought lack of XFmode emulation was the main reason. > I think we've now got two ABI changes to document for the next release > of GCC. If we don't have a good place to document them we should make > it now. Good point. In the past, I've documented MIPS ABI changes in gcc-x.y/changes.html. I don't know how well that worked though. Richard ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 53/63] Static chain fixes 2007-01-10 21:33 ` Richard Sandiford @ 2007-01-10 21:44 ` Richard Sandiford 2007-01-15 0:19 ` Gerald Pfeifer 1 sibling, 0 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 21:44 UTC (permalink / raw) To: law; +Cc: gcc-patches Richard Sandiford <richard@codesourcery.com> writes: > Jeffrey Law <law@redhat.com> writes: >> On Wed, 2007-01-10 at 12:10 +0000, Richard Sandiford wrote: >>> m68k*-elf targets use %a0 as both the incoming structure return address >>> _and_ the static chain pointer. This causes a conflict if a nested function >>> returns a structure. >>> >>> This patch moves the static chain register to %a1 for these targets only. >>> It also generalises the template code to cope with static chain registers >>> other than %a0. >>> >>> Richard >>> >>> >>> gcc/ >>> 200x-xx-xx Nathan Sidwell <nathan@codesourcery.com> >>> Richard Sandiford <richard@codesourcery.com> >>> >>> * config/m68k/m68k.h (M68K_STATIC_CHAIN_REG_NAME): New macro. >>> (INITIALIZE_TRAMPOLINE): Use STATIC_CHAIN_REGNUM. >>> (__transfer_from_trampoline): Use M68K_STATIC_CHAIN_REG_NAME. >>> * config/m68k/m68kelf.h (STATIC_CHAIN_REGNUM): Override. >>> (M68K_STATIC_CHAIN_REG_NAME): Likewise. >>> * config/m68k/netbsd-elf.h (M68K_STATIC_CHAIN_REG_NAME): Likewise. >>> >>> gcc/testsuite/ >>> 200x-xx-xx Nathan Sidwell <nathan@codesourcery.com> >>> >>> * gcc.c-torture/execute/nestfunc-7.c: New. >> Isn't this an ABI change? If so it needs to be documented at the least >> so that users of the m68k elf port aren't caught by surprise. > > Of sorts, although I'm not aware of any actual XFmode emulation > code for ColdFire. I suspect most ColdFire users just avoided > using long double altogether. This may be my ignorance though. ;) > > To be honest, I wasn't involved in the discussions that led to this > change, but I thought lack of XFmode emulation was the main reason. Sigh. Sorry, I'd got myself confused, and thought you were talking about the "long double" change. No, I don't think this one is an ABI change. Nested functions should be internal a translation unit; I don't see how an external module would tell the difference. Richard ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 53/63] Static chain fixes 2007-01-10 21:33 ` Richard Sandiford 2007-01-10 21:44 ` Richard Sandiford @ 2007-01-15 0:19 ` Gerald Pfeifer 1 sibling, 0 replies; 280+ messages in thread From: Gerald Pfeifer @ 2007-01-15 0:19 UTC (permalink / raw) To: Richard Sandiford; +Cc: Jeffrey A Law, gcc-patches On Wed, 10 Jan 2007, Richard Sandiford wrote: >> I think we've now got two ABI changes to document for the next release >> of GCC. If we don't have a good place to document them we should make >> it now. > Good point. In the past, I've documented MIPS ABI changes in > gcc-x.y/changes.html. I don't know how well that worked though. gcc-x.y/changes.html is the best place for documenting such changes, as far as I know. Let's go for that again, I'd say. (And do not forget to submit a news items for our main page once the majority of your changes is in, taking proper credit. ;-) Gerald ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 52/63] Don't use neg.l and negx.l on memory for ColdFire 2007-01-10 12:09 ` [ColdFire 52/63] Don't use neg.l and negx.l on memory for ColdFire Richard Sandiford 2007-01-10 12:10 ` [ColdFire 53/63] Static chain fixes Richard Sandiford @ 2007-01-11 17:54 ` Jeffrey Law 1 sibling, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-01-11 17:54 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches On Wed, 2007-01-10 at 12:09 +0000, Richard Sandiford wrote: > The testsuite had cases in which ColdFire targets would try to use > neg.l and negx.l on memory operands. The patch fixes this by splitting > adddi_dilshr32 into ColdFire and non-ColdFire patterns and only allowing > register destinations in the former. > > I also checked for other uses of {add,sub,neg}x.l with memory operands. > The only two I could find were in the adddi3 and subdi3 patterns, which > supposedly allow both asm operands to be pre-decrement. However, > I think those alternatives are dead code now; flow doesn't use > pre-decrement addressing for an operand if another operand mentions the > same register. (This is true regardless of whether the two operands > are matching operands.) Thus operand 2 might be a pre-decrement, but > because operands 0 and 1 must be the same address, operand 0 won't be > a pre-decrement. FWIW, to make sure, I verified this on the obvious > testcase. I've just removed those alternatives for clarity. > > Richard > > > gcc/ > * config/m68k/m68k.md (adddi_dilshr32): Rename to... > (*adddi_dilshr32): ...this. Fix formatting. Remove commented-out > non-canonical pattern. Restrict to !TARGET_COLDFIRE. > (*adddi_dilshr32_cf): New pattern. > (adddi3, subdi3): Remove first alternatives. > > gcc/testsuite/ > * gcc.c-torture/compile/20061214-1.c: New test. OK. Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 51/63] Don't use move.l CCs for SFmode comparisons 2007-01-10 12:08 ` [ColdFire 51/63] Don't use move.l CCs for SFmode comparisons Richard Sandiford 2007-01-10 12:09 ` [ColdFire 52/63] Don't use neg.l and negx.l on memory for ColdFire Richard Sandiford @ 2007-01-10 18:48 ` Jeffrey Law 1 sibling, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-01-10 18:48 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches On Wed, 2007-01-10 at 12:08 +0000, Richard Sandiford wrote: > One of the glibc tests showed up a miscompilation of csinhf. > notice_update_cc thought that the cc result of a move.l could > be used to implement an SFmode comparison, which is wrong for > the reason explained in the patch. > > Richard > > > gcc/ > * config/m68k/m68k.c (notice_update_cc): If an SFmode move is > implemented using move.l, do not use its cc result for floating-point > comparisons. OK. Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 50/63] Save the PIC register for __builtin_eh_return 2007-01-10 12:07 ` [ColdFire 50/63] Save the PIC register for __builtin_eh_return Richard Sandiford 2007-01-10 12:08 ` [ColdFire 51/63] Don't use move.l CCs for SFmode comparisons Richard Sandiford @ 2007-01-10 19:20 ` Jeffrey Law 2007-01-22 17:52 ` Roman Zippel 2 siblings, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-01-10 19:20 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches On Wed, 2007-01-10 at 12:07 +0000, Richard Sandiford wrote: > g++.dg/eh/registers1.C showed that we weren't restoring %a5 on EH return. > This is because _Unwind_RaiseException was compiled as PIC, and we didn't > think it needed to save and restore the PIC register. There was therefore > no stack slot in which to set up the value of %a5 on EH return. > > Richard > > > gcc/ > * config/m68k/m68k.c (m68k_save_reg): Save the PIC register in > functions that call eh_return. OK. Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 50/63] Save the PIC register for __builtin_eh_return 2007-01-10 12:07 ` [ColdFire 50/63] Save the PIC register for __builtin_eh_return Richard Sandiford 2007-01-10 12:08 ` [ColdFire 51/63] Don't use move.l CCs for SFmode comparisons Richard Sandiford 2007-01-10 19:20 ` [ColdFire 50/63] Save the PIC register for __builtin_eh_return Jeffrey Law @ 2007-01-22 17:52 ` Roman Zippel 2007-01-22 18:46 ` Richard Sandiford 2 siblings, 1 reply; 280+ messages in thread From: Roman Zippel @ 2007-01-22 17:52 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches Hi, On Wed, 10 Jan 2007, Richard Sandiford wrote: > g++.dg/eh/registers1.C showed that we weren't restoring %a5 on EH return. > This is because _Unwind_RaiseException was compiled as PIC, and we didn't > think it needed to save and restore the PIC register. There was therefore > no stack slot in which to set up the value of %a5 on EH return. > > Richard > > > gcc/ > * config/m68k/m68k.c (m68k_save_reg): Save the PIC register in > functions that call eh_return. > > Index: gcc/config/m68k/m68k.c > =================================================================== > --- gcc/config/m68k/m68k.c 2007-01-09 15:02:23.000000000 +0000 > +++ gcc/config/m68k/m68k.c 2007-01-09 15:02:23.000000000 +0000 > @@ -744,6 +744,9 @@ m68k_save_reg (unsigned int regno, bool > { > if (flag_pic && regno == PIC_OFFSET_TABLE_REGNUM) > { > + /* We need to restore the PIC register on exceptional returns. */ > + if (current_function_calls_eh_return) > + return true; > if (current_function_uses_pic_offset_table) > return true; > /* Reload may introduce constant pool references into a function I know that i386 does the same, but I think it would be more correct to use current_function_has_nonlocal_label instead. This is set by expand_builtin_unwind_init() to save all registers and reload() skips the pic register because it's fixed. bye, Roman ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 50/63] Save the PIC register for __builtin_eh_return 2007-01-22 17:52 ` Roman Zippel @ 2007-01-22 18:46 ` Richard Sandiford 2007-01-24 19:47 ` Jeffrey Law 0 siblings, 1 reply; 280+ messages in thread From: Richard Sandiford @ 2007-01-22 18:46 UTC (permalink / raw) To: Roman Zippel; +Cc: gcc-patches, law Roman Zippel <zippel@linux-m68k.org> writes: > On Wed, 10 Jan 2007, Richard Sandiford wrote: >> g++.dg/eh/registers1.C showed that we weren't restoring %a5 on EH return. >> This is because _Unwind_RaiseException was compiled as PIC, and we didn't >> think it needed to save and restore the PIC register. There was therefore >> no stack slot in which to set up the value of %a5 on EH return. >> >> Richard >> >> >> gcc/ >> * config/m68k/m68k.c (m68k_save_reg): Save the PIC register in >> functions that call eh_return. >> >> Index: gcc/config/m68k/m68k.c >> =================================================================== >> --- gcc/config/m68k/m68k.c 2007-01-09 15:02:23.000000000 +0000 >> +++ gcc/config/m68k/m68k.c 2007-01-09 15:02:23.000000000 +0000 >> @@ -744,6 +744,9 @@ m68k_save_reg (unsigned int regno, bool >> { >> if (flag_pic && regno == PIC_OFFSET_TABLE_REGNUM) >> { >> + /* We need to restore the PIC register on exceptional returns. */ >> + if (current_function_calls_eh_return) >> + return true; >> if (current_function_uses_pic_offset_table) >> return true; >> /* Reload may introduce constant pool references into a function > > I know that i386 does the same, but I think it would be more correct to > use current_function_has_nonlocal_label instead. This is set by > expand_builtin_unwind_init() to save all registers and reload() skips the > pic register because it's fixed. Good point. Jeff, is the patch OK with that change? Richard ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 50/63] Save the PIC register for __builtin_eh_return 2007-01-22 18:46 ` Richard Sandiford @ 2007-01-24 19:47 ` Jeffrey Law 0 siblings, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-01-24 19:47 UTC (permalink / raw) To: Richard Sandiford; +Cc: Roman Zippel, gcc-patches On Mon, 2007-01-22 at 18:46 +0000, Richard Sandiford wrote: > Roman Zippel <zippel@linux-m68k.org> writes: > > On Wed, 10 Jan 2007, Richard Sandiford wrote: > >> g++.dg/eh/registers1.C showed that we weren't restoring %a5 on EH return. > >> This is because _Unwind_RaiseException was compiled as PIC, and we didn't > >> think it needed to save and restore the PIC register. There was therefore > >> no stack slot in which to set up the value of %a5 on EH return. > >> > >> Richard > >> > >> > >> gcc/ > >> * config/m68k/m68k.c (m68k_save_reg): Save the PIC register in > >> functions that call eh_return. > >> > >> Index: gcc/config/m68k/m68k.c > >> =================================================================== > >> --- gcc/config/m68k/m68k.c 2007-01-09 15:02:23.000000000 +0000 > >> +++ gcc/config/m68k/m68k.c 2007-01-09 15:02:23.000000000 +0000 > >> @@ -744,6 +744,9 @@ m68k_save_reg (unsigned int regno, bool > >> { > >> if (flag_pic && regno == PIC_OFFSET_TABLE_REGNUM) > >> { > >> + /* We need to restore the PIC register on exceptional returns. */ > >> + if (current_function_calls_eh_return) > >> + return true; > >> if (current_function_uses_pic_offset_table) > >> return true; > >> /* Reload may introduce constant pool references into a function > > > > I know that i386 does the same, but I think it would be more correct to > > use current_function_has_nonlocal_label instead. This is set by > > expand_builtin_unwind_init() to save all registers and reload() skips the > > pic register because it's fixed. > > Good point. Jeff, is the patch OK with that change? Yes. jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 49/63] Save and restore the PIC register when using a constant pool 2007-01-10 12:06 ` [ColdFire 49/63] Save and restore the PIC register when using a constant pool Richard Sandiford 2007-01-10 12:07 ` [ColdFire 50/63] Save the PIC register for __builtin_eh_return Richard Sandiford @ 2007-01-11 17:52 ` Jeffrey Law 1 sibling, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-01-11 17:52 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches On Wed, 2007-01-10 at 12:05 +0000, Richard Sandiford wrote: > Reload can legitimately introduce constant pool references into > a function that didn't otherwise have them. We're interested > in three events when this happens: > > (a) reload decides to force something into the constant pool > (b) reload and config/m68k together decide the final frame layout > (c) reload emits the input and output reload instructions > > These events happen in the order listed. > > When generating PIC, the PIC form of the address is introduced > by (c), which in turn sets current_function_uses_pic_offset_table. > However, we need to know in (b) whether to save the PIC register. > AIUI, the canonical way of dealing with this is to check > current_function_uses_const_pool. > > Richard > > > gcc/ > * config/m68k/m68k.c (m68k_save_reg): Save the PIC register in > functions that need a constant pool. OK. IIRC this fixes the longest standing m68k PIC bug that I was aware of. Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 48/63] Fix the 'T' constraint 2007-01-10 12:04 ` [ColdFire 48/63] Fix the 'T' constraint Richard Sandiford 2007-01-10 12:06 ` [ColdFire 49/63] Save and restore the PIC register when using a constant pool Richard Sandiford @ 2007-01-10 18:47 ` Jeffrey Law 1 sibling, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-01-10 18:47 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches On Wed, 2007-01-10 at 12:04 +0000, Richard Sandiford wrote: > After having misapplied a patch, I came across a bug in which 'T' > was allowing symbolic constants for non-pcrel PIC. The comment reads: > > `T' is for operands that satisfy 's' when -mpcrel is not in effect. > > and 's' doesn't accept anything if flag_pic. > > This bug became latent again once I'd fixed my initial mistake, > but I still think it should be fixed. > > Richard > > > gcc/ > * config/m68k/m68k.h (EXTRA_CONSTRAINT): Stop the 'T' constraint > from accepting 's' constraints if flag_pic. OK. Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 47/63] Fix PR target/28181 2007-01-10 12:03 ` [ColdFire 47/63] Fix PR target/28181 Richard Sandiford 2007-01-10 12:04 ` [ColdFire 48/63] Fix the 'T' constraint Richard Sandiford @ 2007-01-16 18:16 ` Jeffrey Law 1 sibling, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-01-16 18:16 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches, rask, zippel On Wed, 2007-01-10 at 12:03 +0000, Richard Sandiford wrote: > This patch fixes PR target/28181. See the thread starting at: > > http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00766.html > > for previous discussion about this PR. The problem is that we > may sometimes need to reload paradoxical HImode or SImode subregs > of spilled QImode pseudos. reload sees no reason not to generate > such reloads for address registers because address registers are > allowed to store HImode and SImode values. However, it may then > decide to reload the inner QImode spill slot rather than an > HImode or SImode MEM. Such loads cannot be done with address > registers. > > As I said in my follow-up to the above message, I think the correct > fix is to (a) allow address registers to hold bytes and (b) to define > SECONDARY_RELOAD_CLASS in such a way that we require a DATA_REGS > temporary when loading or storing them. No change is needed to the > movqi patterns because they already handle moves from constants to > address registers, and between address registers and data registers, > despite what m68k_regno_mode_ok says. > > Richard > > > gcc/ > PR target/28181 > * config/m68k/m68k-protos.h (m68k_secondary_reload_class): Declare. > (m68k_preferred_reload_class): Likewise. > * config/m68k/m68k.h (HARD_REGNO_MODE_OK): Remove duplicated comment. > (SECONDARY_RELOAD_CLASS): Define. > (PREFERRED_RELOAD_CLASS): Use m68k_preferred_reload_class. > (LIMIT_RELOAD_CLASS): Delete. > * config/m68k/m68k.c (m68k_regno_mode_ok): Don't prevent address > registers from storing bytes. > (m68k_secondary_reload_class): New function. > (m68k_preferred_reload_class): Likewise. OK. Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 46/63] Add support for unwinding through signal handlers 2007-01-10 12:01 ` [ColdFire 46/63] Add support for unwinding through signal handlers Richard Sandiford 2007-01-10 12:03 ` [ColdFire 47/63] Fix PR target/28181 Richard Sandiford @ 2007-01-16 1:38 ` Roman Zippel 2007-01-16 5:20 ` Richard Sandiford 1 sibling, 1 reply; 280+ messages in thread From: Roman Zippel @ 2007-01-16 1:38 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches Hi, On Wed, 10 Jan 2007, Richard Sandiford wrote: > This patch adds support for unwinding through linux signal trampolines. > Only the ColdFire version has been properly tested, but I hope the 680x0 > version stands a good chance of being OK. I see a few problems: - it assumes a fixed glibc with a correct ucontext - d0/d1/a0/a1 aren't restored from sigcontext - unconditional fp restore (in case of an idle fpu, it would restore random data) - signal_frame isn't set - the knowledge about the stack layout (the footer structs) is not a good idea, that part is not guaranteed, a pointer to the context is passed on the stack. bye, Roman ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 46/63] Add support for unwinding through signal handlers 2007-01-16 1:38 ` [ColdFire 46/63] Add support for unwinding through signal handlers Roman Zippel @ 2007-01-16 5:20 ` Richard Sandiford 2007-01-22 17:16 ` Roman Zippel ` (2 more replies) 0 siblings, 3 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-16 5:20 UTC (permalink / raw) To: Roman Zippel; +Cc: gcc-patches Roman Zippel <zippel@linux-m68k.org> writes: > On Wed, 10 Jan 2007, Richard Sandiford wrote: >> This patch adds support for unwinding through linux signal trampolines. >> Only the ColdFire version has been properly tested, but I hope the 680x0 >> version stands a good chance of being OK. > > I see a few problems: > - it assumes a fixed glibc with a correct ucontext > - d0/d1/a0/a1 aren't restored from sigcontext > - unconditional fp restore (in case of an idle fpu, it would restore > random data) > - signal_frame isn't set > - the knowledge about the stack layout (the footer structs) is not a > good idea, that part is not guaranteed, a pointer to the context is > passed on the stack. In that case could you propose a counter-patch? Richard ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 46/63] Add support for unwinding through signal handlers 2007-01-16 5:20 ` Richard Sandiford @ 2007-01-22 17:16 ` Roman Zippel 2007-01-29 9:54 ` Richard Sandiford 2007-01-22 17:46 ` [m68k 2/2] unwind support for signal handler Roman Zippel 2007-01-22 17:49 ` [m68k 1/2] define DWARF_FRAME_RETURN_COLUMN Roman Zippel 2 siblings, 1 reply; 280+ messages in thread From: Roman Zippel @ 2007-01-22 17:16 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches Hi, On Tue, 16 Jan 2007, Richard Sandiford wrote: > In that case could you propose a counter-patch? My version of this patch depends on another patch, but it's simple enough so I'll send that too. Both are part of the Debian gcc, so have been thoroughly tested there, although I added the ColdFire pieces from your patch. bye, Roman ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 46/63] Add support for unwinding through signal handlers 2007-01-22 17:16 ` Roman Zippel @ 2007-01-29 9:54 ` Richard Sandiford 0 siblings, 0 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-29 9:54 UTC (permalink / raw) To: Roman Zippel; +Cc: gcc-patches Roman Zippel <zippel@linux-m68k.org> writes: > On Tue, 16 Jan 2007, Richard Sandiford wrote: >> In that case could you propose a counter-patch? > > My version of this patch depends on another patch, but it's simple enough > so I'll send that too. Both are part of the Debian gcc, so have been > thoroughly tested there, although I added the ColdFire pieces from your > patch. Thanks. I tested your patch on our ColdFire board and the ColdFire version seems to work fine. (And sorry for not responding earlier, the board was otherwise engaged.) Richard ^ permalink raw reply [flat|nested] 280+ messages in thread
* [m68k 2/2] unwind support for signal handler 2007-01-16 5:20 ` Richard Sandiford 2007-01-22 17:16 ` Roman Zippel @ 2007-01-22 17:46 ` Roman Zippel 2007-01-28 9:04 ` Andreas Schwab 2007-01-22 17:49 ` [m68k 1/2] define DWARF_FRAME_RETURN_COLUMN Roman Zippel 2 siblings, 1 reply; 280+ messages in thread From: Roman Zippel @ 2007-01-22 17:46 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches Hi, This adds support for unwinding through linux signal trampolines. 2006-01-22 Roman Zippel <zippel@linux-m68k.org> * config/m68k/linux.h (MD_UNWIND_SUPPORT): Define. * config/m68k/linux-unwind.h: New file. --- gcc/config/m68k/linux-unwind.h | 153 +++++++++++++++++++++++++++++++++++++++++ gcc/config/m68k/linux.h | 2 2 files changed, 155 insertions(+) Index: egcs/gcc/config/m68k/linux-unwind.h =================================================================== --- /dev/null +++ egcs/gcc/config/m68k/linux-unwind.h @@ -0,0 +1,153 @@ +/* DWARF2 EH unwinding support for Linux/m68k. + Copyright (C) 2006 Free Software Foundation, Inc. + +This file is part of GCC. + +GCC is free software; you can redistribute it and/or modify +it under the terms of the GNU General Public License as published by +the Free Software Foundation; either version 2, or (at your option) +any later version. + +In addition to the permissions in the GNU General Public License, the +Free Software Foundation gives you unlimited permission to link the +compiled version of this file with other programs, and to distribute +those programs without any restriction coming from the use of this +file. (The General Public License restrictions do apply in other +respects; for example, they cover modification of the file, and +distribution when not linked into another program.) + +GCC is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. + +You should have received a copy of the GNU General Public License +along with GCC; see the file COPYING. If not, write to +the Free Software Foundation, 51 Franklin Street, Fifth Floor, +Boston, MA 02110-1301, USA. */ + +/* Do code reading to identify a signal frame, and set the frame + state data appropriately. See unwind-dw2.c for the structs. + Don't use this at all if inhibit_libc is used. */ + +#ifndef inhibit_libc + +#include <signal.h> + +/* <sys/ucontext.h> is unfortunaly broken right now */ +struct uw_ucontext { + unsigned long uc_flags; + struct ucontext *uc_link; + stack_t uc_stack; + mcontext_t uc_mcontext; + unsigned long uc_filler[80]; + __sigset_t uc_sigmask; +}; + +#define MD_FALLBACK_FRAME_STATE_FOR m68k_fallback_frame_state + +#ifdef __mcoldfire__ +#define M68K_FP_SIZE 8 +#else +#define M68K_FP_SIZE 12 +#endif + +static _Unwind_Reason_Code +m68k_fallback_frame_state (struct _Unwind_Context *context, + _Unwind_FrameState *fs) +{ + unsigned short *pc = context->ra; + long cfa; + + /* moveq #__NR_sigreturn,%d0; trap #0 */ + if (pc[0] == 0x7077 && pc[1] == 0x4e40) + { + struct sigcontext *sc; + + /* context is passed as the 3rd argument */ + sc = *(struct sigcontext **)(context->cfa + 8); + + cfa = sc->sc_usp; + fs->regs.cfa_how = CFA_REG_OFFSET; + fs->regs.cfa_reg = 15; + fs->regs.cfa_offset = cfa - (long) context->cfa; + + fs->regs.reg[0].how = REG_SAVED_OFFSET; + fs->regs.reg[0].loc.offset = (long)&sc->sc_d0 - cfa; + fs->regs.reg[1].how = REG_SAVED_OFFSET; + fs->regs.reg[1].loc.offset = (long)&sc->sc_d1 - cfa; + fs->regs.reg[8].how = REG_SAVED_OFFSET; + fs->regs.reg[8].loc.offset = (long)&sc->sc_a0 - cfa; + fs->regs.reg[9].how = REG_SAVED_OFFSET; + fs->regs.reg[9].loc.offset = (long)&sc->sc_a1 - cfa; + + fs->regs.reg[24].how = REG_SAVED_OFFSET; + fs->regs.reg[24].loc.offset = (long)&sc->sc_pc - cfa; + + if (*(int *)sc->sc_fpstate) + { + int *fpregs = (int *)sc->sc_fpregs; + + fs->regs.reg[16].how = REG_SAVED_OFFSET; + fs->regs.reg[16].loc.offset = (long)&fpregs[0] - cfa; + fs->regs.reg[17].how = REG_SAVED_OFFSET; + fs->regs.reg[17].loc.offset = (long)&fpregs[M68K_FP_SIZE/4] - cfa; + } + } +#ifdef __mcoldfire__ + /* move.l #__NR_rt_sigreturn,%d0; trap #0 */ + else if (pc[0] == 0x203c && pc[1] == 0x0000 && + pc[2] == 0x00ad && pc[3] == 0x4e40) +#else + /* moveq #~__NR_rt_sigreturn,%d0; not.b %d0; trap #0 */ + else if (pc[0] == 0x7052 && pc[1] == 0x4600 && pc[2] == 0x4e40) +#endif + { + struct uw_ucontext *uc; + greg_t *gregs; + int i; + + /* context is passed as the 3rd argument */ + uc = *(struct uw_ucontext **)(context->cfa + 8); + + gregs = uc->uc_mcontext.gregs; + cfa = gregs[15]; + fs->regs.cfa_how = CFA_REG_OFFSET; + fs->regs.cfa_reg = 15; + fs->regs.cfa_offset = cfa - (long) context->cfa; + + /* register %d0-%d7/%a0-%a6 */ + for (i = 0; i <= 14; i++) + { + fs->regs.reg[i].how = REG_SAVED_OFFSET; + fs->regs.reg[i].loc.offset = (long)&gregs[i] - cfa; + } + + /* return address */ + fs->regs.reg[24].how = REG_SAVED_OFFSET; + fs->regs.reg[24].loc.offset = (long)&gregs[16] - cfa; + +#define uc_fpstate uc_filler[0] + + if (uc->uc_fpstate) + { + long fpregs = (long)uc->uc_mcontext.fpregs.f_fpregs; + + /* register %fp0-%fp7 */ + for (i = 16; i <= 23; i++) + { + fs->regs.reg[i].how = REG_SAVED_OFFSET; + fs->regs.reg[i].loc.offset = fpregs - cfa; + fpregs += M68K_FP_SIZE; + } + } + } + else + return _URC_END_OF_STACK; + + fs->retaddr_column = 24; + fs->signal_frame = 1; + + return _URC_NO_REASON; +} +#endif /* ifdef inhibit_libc */ Index: egcs/gcc/config/m68k/linux.h =================================================================== --- egcs.orig/gcc/config/m68k/linux.h +++ egcs/gcc/config/m68k/linux.h @@ -229,3 +229,5 @@ Boston, MA 02110-1301, USA. */ } #define TARGET_ASM_FILE_END file_end_indicate_exec_stack + +#define MD_UNWIND_SUPPORT "config/m68k/linux-unwind.h" ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [m68k 2/2] unwind support for signal handler 2007-01-22 17:46 ` [m68k 2/2] unwind support for signal handler Roman Zippel @ 2007-01-28 9:04 ` Andreas Schwab 0 siblings, 0 replies; 280+ messages in thread From: Andreas Schwab @ 2007-01-28 9:04 UTC (permalink / raw) To: Roman Zippel; +Cc: Richard Sandiford, gcc-patches Roman Zippel <zippel@linux-m68k.org> writes: > 2006-01-22 Roman Zippel <zippel@linux-m68k.org> > > * config/m68k/linux.h (MD_UNWIND_SUPPORT): Define. > * config/m68k/linux-unwind.h: New file. This is ok, except for a few style nits: > +static _Unwind_Reason_Code > +m68k_fallback_frame_state (struct _Unwind_Context *context, > + _Unwind_FrameState *fs) > +{ > + unsigned short *pc = context->ra; > + long cfa; > + > + /* moveq #__NR_sigreturn,%d0; trap #0 */ > + if (pc[0] == 0x7077 && pc[1] == 0x4e40) > + { > + struct sigcontext *sc; > + > + /* context is passed as the 3rd argument */ Comments should be properly capitalized, with period and two spaces after it. > + sc = *(struct sigcontext **)(context->cfa + 8); Please put a space after the cast, here and below. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 280+ messages in thread
* [m68k 1/2] define DWARF_FRAME_RETURN_COLUMN 2007-01-16 5:20 ` Richard Sandiford 2007-01-22 17:16 ` Roman Zippel 2007-01-22 17:46 ` [m68k 2/2] unwind support for signal handler Roman Zippel @ 2007-01-22 17:49 ` Roman Zippel 2007-01-22 19:51 ` Richard Sandiford 2 siblings, 1 reply; 280+ messages in thread From: Roman Zippel @ 2007-01-22 17:49 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches Hi, This explicitely defines 24 as DWARF_FRAME_RETURN_COLUMN for m68k and adds 25 as an alternative. IMO it's a bit unfortunate that these are automatically defined, as they have consequences for the exception ABI. Before this the return column was 25, but e.g. binutils uses 24 as return column and this wasn't recognized, so to unify this use 24 now (which nicely matches the arg pointer), but still accept 25. 2006-01-22 Roman Zippel <zippel@linux-m68k.org> * config/m68k/m68k.c (m68k_regno_mode_ok): return a valid size for the return column (which matches the argpointer) * config/m68k/m68k.h (DWARF_FRAME_REGISTERS,DWARF_FRAME_RETURN_COLUMN, DWARF_ALT_FRAME_RETURN_COLUMN): new macros (HARD_REGNO_NREGS): check upper limit for fp registers --- gcc/config/m68k/m68k.c | 4 ++++ gcc/config/m68k/m68k.h | 9 ++++++++- 2 files changed, 12 insertions(+), 1 deletion(-) Index: egcs/gcc/config/m68k/m68k.c =================================================================== --- egcs.orig/gcc/config/m68k/m68k.c +++ egcs/gcc/config/m68k/m68k.c @@ -3797,6 +3797,10 @@ m68k_regno_mode_ok (int regno, enum mach && GET_MODE_UNIT_SIZE (mode) <= TARGET_FP_REG_SIZE) return true; } + else if (regno == 24) + { + return GET_MODE_SIZE (mode) == 4; + } return false; } Index: egcs/gcc/config/m68k/m68k.h =================================================================== --- egcs.orig/gcc/config/m68k/m68k.h +++ egcs/gcc/config/m68k/m68k.h @@ -315,6 +315,13 @@ Boston, MA 02110-1301, USA. */ register elimination. */ #define FIRST_PSEUDO_REGISTER 25 +/* Number of hardware registers that go into the DWARF-2 unwind info. This + should be 24, but to prevent compability problems leave it at 25. */ +#define DWARF_FRAME_REGISTERS 25 + +#define DWARF_FRAME_RETURN_COLUMN 24 +#define DWARF_ALT_FRAME_RETURN_COLUMN 25 + /* All m68k targets (except AmigaOS) use %a5 as the PIC register */ #define PIC_OFFSET_TABLE_REGNUM (flag_pic ? 13 : INVALID_REGNUM) @@ -392,7 +399,7 @@ Boston, MA 02110-1301, USA. */ for the 68881 registers, a single register is always enough for anything that can be stored in them at all. */ #define HARD_REGNO_NREGS(REGNO, MODE) \ - ((REGNO) >= 16 ? GET_MODE_NUNITS (MODE) \ + (IN_RANGE (REGNO, 16, 23) ? GET_MODE_NUNITS (MODE) \ : ((GET_MODE_SIZE (MODE) + UNITS_PER_WORD - 1) / UNITS_PER_WORD)) /* A C expression that is nonzero if hard register NEW_REG can be ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [m68k 1/2] define DWARF_FRAME_RETURN_COLUMN 2007-01-22 17:49 ` [m68k 1/2] define DWARF_FRAME_RETURN_COLUMN Roman Zippel @ 2007-01-22 19:51 ` Richard Sandiford 2007-01-22 20:15 ` Andreas Schwab 2007-01-22 23:03 ` Roman Zippel 0 siblings, 2 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-22 19:51 UTC (permalink / raw) To: Roman Zippel; +Cc: gcc-patches Roman Zippel <zippel@linux-m68k.org> writes: > This explicitely defines 24 as DWARF_FRAME_RETURN_COLUMN for m68k and adds > 25 as an alternative. IMO it's a bit unfortunate that these are > automatically defined, as they have consequences for the exception ABI. > Before this the return column was 25, but e.g. binutils uses 24 as return > column and this wasn't recognized, so to unify this use 24 now (which > nicely matches the arg pointer), but still accept 25. > > 2006-01-22 Roman Zippel <zippel@linux-m68k.org> > > * config/m68k/m68k.c (m68k_regno_mode_ok): return a valid size for > the return column (which matches the argpointer) > * config/m68k/m68k.h (DWARF_FRAME_REGISTERS,DWARF_FRAME_RETURN_COLUMN, > DWARF_ALT_FRAME_RETURN_COLUMN): new macros > (HARD_REGNO_NREGS): check upper limit for fp registers I'm a little suspicious about the way the patch is implemented. It's effectively saying that ARG_POINTER_REGNUM is a real register that holds the incoming return address. This isn't true on either count. It isn't a real register, and it points at a stack slot that contains the return address. IMO, ARG_POINTER_REGNUM shouldn't really have any dwarf mapping at all. (In other words, DWARF_FRAME_REGNUM (ARG_POINTER_REGNUM) should be -1.) Also, the documentation says: @defmac DWARF_ALT_FRAME_RETURN_COLUMN A C expression whose value is an integer giving a DWARF 2 column number that may be used as an alternate return column. This should be defined only if @code{DWARF_FRAME_RETURN_COLUMN} is set to a general register, but an alternate column needs to be used for signal frames. @end defmac DWARF_FRAME_RETURN_COLUMN isn't a general register and you're not using the macro to specify a different column for signal frames. If I've understood correctly, the real problem here is that binutils has used an undefined dwarf register (24) in its CIEs, and element 24 of the dwarf register size table isn't set to sizeof (Pmode). Is that right? If so, the obvious thing would be to fix binutils. I'm not sure how its unwind info would ever have worked as-is. But if you don't think that's acceptable, then I don't think we should pretend that ARG_POINTER_REGNUM is the return address register. I think the pedantically correct fix is to: (1) Extend the DWARF_ALT_FRAME_RETURN_COLUMN so that it can cope with cases where (refering to dwarf2out.c) wrote_return_column is false. I.e. allow ports to define two non-general "registers" that can act as return address columns. (2) Define the following: -------------------------------------------------------------------- #define DWARF_FRAME_REGISTERS 25 #define DWARF_FRAME_RETURN_COLUMN 24 #define DWARF_ALT_FRAME_RETURN_COLUMN 25 #define DWARF_FRAME_REGNUM(REG) \ (INT_REGNO_P (REG) || FP_REGNO_P (REG) ? (REG) : -1) -------------------------------------------------------------------- I can prepare a patch on those lines if you agree, but I'd like to push harder on the binutils fix first. Richard ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [m68k 1/2] define DWARF_FRAME_RETURN_COLUMN 2007-01-22 19:51 ` Richard Sandiford @ 2007-01-22 20:15 ` Andreas Schwab 2007-01-22 20:23 ` Richard Sandiford 2007-01-22 23:03 ` Roman Zippel 1 sibling, 1 reply; 280+ messages in thread From: Andreas Schwab @ 2007-01-22 20:15 UTC (permalink / raw) To: richard; +Cc: gcc-patches, Roman Zippel Richard Sandiford <richard@codesourcery.com> writes: > If I've understood correctly, the real problem here is that binutils has > used an undefined dwarf register (24) in its CIEs, and element 24 of the > dwarf register size table isn't set to sizeof (Pmode). Is that right? When DWARF support for m68k was added to binutils ARG_POINTER_REGNUM didn't exist yet, and gcc used 24 for the return column. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [m68k 1/2] define DWARF_FRAME_RETURN_COLUMN 2007-01-22 20:15 ` Andreas Schwab @ 2007-01-22 20:23 ` Richard Sandiford 2007-01-22 21:06 ` Andreas Schwab 0 siblings, 1 reply; 280+ messages in thread From: Richard Sandiford @ 2007-01-22 20:23 UTC (permalink / raw) To: Andreas Schwab; +Cc: gcc-patches, Roman Zippel Andreas Schwab <schwab@suse.de> writes: > Richard Sandiford <richard@codesourcery.com> writes: >> If I've understood correctly, the real problem here is that binutils has >> used an undefined dwarf register (24) in its CIEs, and element 24 of the >> dwarf register size table isn't set to sizeof (Pmode). Is that right? > > When DWARF support for m68k was added to binutils ARG_POINTER_REGNUM > didn't exist yet, and gcc used 24 for the return column. Ah. That's indeed unfortunate. So the idea of "fixing" binutils is obviously out then. Any thoughts on whether the gcc fix I suggested is the right one? Richard ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [m68k 1/2] define DWARF_FRAME_RETURN_COLUMN 2007-01-22 20:23 ` Richard Sandiford @ 2007-01-22 21:06 ` Andreas Schwab 2007-01-22 22:08 ` Richard Sandiford 0 siblings, 1 reply; 280+ messages in thread From: Andreas Schwab @ 2007-01-22 21:06 UTC (permalink / raw) To: gcc-patches; +Cc: Roman Zippel, richard Richard Sandiford <richard@codesourcery.com> writes: > Andreas Schwab <schwab@suse.de> writes: >> Richard Sandiford <richard@codesourcery.com> writes: >>> If I've understood correctly, the real problem here is that binutils has >>> used an undefined dwarf register (24) in its CIEs, and element 24 of the >>> dwarf register size table isn't set to sizeof (Pmode). Is that right? >> >> When DWARF support for m68k was added to binutils ARG_POINTER_REGNUM >> didn't exist yet, and gcc used 24 for the return column. > > Ah. That's indeed unfortunate. So the idea of "fixing" binutils > is obviously out then. > > Any thoughts on whether the gcc fix I suggested is the right one? IIUC the right fix would be to define DWARF_FRAME_REGISTERS to 25 and modify DWARF_FRAME_REGNUM so that ARG_POINTER_REGNUM is mapped outside of the DWARF_FRAME_REGISTERS range, since it is not a hard register. That should restore the behaviour of gcc before the addition of argptr. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [m68k 1/2] define DWARF_FRAME_RETURN_COLUMN 2007-01-22 21:06 ` Andreas Schwab @ 2007-01-22 22:08 ` Richard Sandiford 2007-01-22 22:57 ` Andreas Schwab 0 siblings, 1 reply; 280+ messages in thread From: Richard Sandiford @ 2007-01-22 22:08 UTC (permalink / raw) To: Andreas Schwab; +Cc: gcc-patches, Roman Zippel Andreas Schwab <schwab@suse.de> writes: > Richard Sandiford <richard@codesourcery.com> writes: >> Andreas Schwab <schwab@suse.de> writes: >>> Richard Sandiford <richard@codesourcery.com> writes: >>>> If I've understood correctly, the real problem here is that binutils has >>>> used an undefined dwarf register (24) in its CIEs, and element 24 of the >>>> dwarf register size table isn't set to sizeof (Pmode). Is that right? >>> >>> When DWARF support for m68k was added to binutils ARG_POINTER_REGNUM >>> didn't exist yet, and gcc used 24 for the return column. >> >> Ah. That's indeed unfortunate. So the idea of "fixing" binutils >> is obviously out then. >> >> Any thoughts on whether the gcc fix I suggested is the right one? > > IIUC the right fix would be to define DWARF_FRAME_REGISTERS to 25 and > modify DWARF_FRAME_REGNUM so that ARG_POINTER_REGNUM is mapped outside of > the DWARF_FRAME_REGISTERS range, since it is not a hard register. That > should restore the behaviour of gcc before the addition of argptr. OK, that sounds like what I suggested: > (1) Extend the DWARF_ALT_FRAME_RETURN_COLUMN so that it can cope with > cases where (refering to dwarf2out.c) wrote_return_column is > false. I.e. allow ports to define two non-general "registers" > that can act as return address columns. > > (2) Define the following: > > -------------------------------------------------------------------- > #define DWARF_FRAME_REGISTERS 25 > #define DWARF_FRAME_RETURN_COLUMN 24 > #define DWARF_ALT_FRAME_RETURN_COLUMN 25 > #define DWARF_FRAME_REGNUM(REG) \ > (INT_REGNO_P (REG) || FP_REGNO_P (REG) ? (REG) : -1) > -------------------------------------------------------------------- but I'm not 100% sure if your answer is a "yes" or if you're suggesting something else. Richard ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [m68k 1/2] define DWARF_FRAME_RETURN_COLUMN 2007-01-22 22:08 ` Richard Sandiford @ 2007-01-22 22:57 ` Andreas Schwab 2007-01-23 7:40 ` Richard Sandiford 0 siblings, 1 reply; 280+ messages in thread From: Andreas Schwab @ 2007-01-22 22:57 UTC (permalink / raw) To: gcc-patches; +Cc: Roman Zippel, richard Richard Sandiford <richard@codesourcery.com> writes: >> (2) Define the following: >> >> -------------------------------------------------------------------- >> #define DWARF_FRAME_REGISTERS 25 >> #define DWARF_FRAME_RETURN_COLUMN 24 >> #define DWARF_ALT_FRAME_RETURN_COLUMN 25 >> #define DWARF_FRAME_REGNUM(REG) \ >> (INT_REGNO_P (REG) || FP_REGNO_P (REG) ? (REG) : -1) >> -------------------------------------------------------------------- > > but I'm not 100% sure if your answer is a "yes" or if you're suggesting > something else. I don't think expand_builtin_init_dwarf_reg_sizes can cope with these definitions. DWARF_FRAME_REGNUM cannot return something negative unless DWARF2_FRAME_REG_OUT maps that back to something >= DWARF_FRAME_REGISTERS, and defining DWARF_ALT_FRAME_RETURN_COLUMN will trigger an assert, since there is no register that maps to DWARF_FRAME_RETURN_COLUMN. These two definitions should be all that is needed: #define DWARF_FRAME_REGISTERS 24 #define DWARF_FRAME_REGNUM(REG) \ (INT_REGNO_P (REG) || FP_REGNO_P (REG) ? (REG) : 25) Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [m68k 1/2] define DWARF_FRAME_RETURN_COLUMN 2007-01-22 22:57 ` Andreas Schwab @ 2007-01-23 7:40 ` Richard Sandiford 0 siblings, 0 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-23 7:40 UTC (permalink / raw) To: Andreas Schwab; +Cc: gcc-patches, Roman Zippel Andreas Schwab <schwab@suse.de> writes: > Richard Sandiford <richard@codesourcery.com> writes: > >>> (2) Define the following: >>> >>> -------------------------------------------------------------------- >>> #define DWARF_FRAME_REGISTERS 25 >>> #define DWARF_FRAME_RETURN_COLUMN 24 >>> #define DWARF_ALT_FRAME_RETURN_COLUMN 25 >>> #define DWARF_FRAME_REGNUM(REG) \ >>> (INT_REGNO_P (REG) || FP_REGNO_P (REG) ? (REG) : -1) >>> -------------------------------------------------------------------- >> >> but I'm not 100% sure if your answer is a "yes" or if you're suggesting >> something else. > > I don't think expand_builtin_init_dwarf_reg_sizes can cope with these > definitions. DWARF_FRAME_REGNUM cannot return something negative unless > DWARF2_FRAME_REG_OUT maps that back to something >= DWARF_FRAME_REGISTERS, > and defining DWARF_ALT_FRAME_RETURN_COLUMN will trigger an assert, since > there is no register that maps to DWARF_FRAME_RETURN_COLUMN. > > These two definitions should be all that is needed: > > #define DWARF_FRAME_REGISTERS 24 > #define DWARF_FRAME_REGNUM(REG) \ > (INT_REGNO_P (REG) || FP_REGNO_P (REG) ? (REG) : 25) But this doesn't preserve the backwards-compatibility that Roman was aiming for (and that I agree is a good idea). Attempting to use register 25 as the return register would crash the unwinder. You're right about the -1 thing, of course; I meant to use INVALID_REGNUM. That's what comes of doing something from memory. Richard ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [m68k 1/2] define DWARF_FRAME_RETURN_COLUMN 2007-01-22 19:51 ` Richard Sandiford 2007-01-22 20:15 ` Andreas Schwab @ 2007-01-22 23:03 ` Roman Zippel 2007-01-23 7:55 ` Richard Sandiford 1 sibling, 1 reply; 280+ messages in thread From: Roman Zippel @ 2007-01-22 23:03 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches Hi, On Mon, 22 Jan 2007, Richard Sandiford wrote: > Roman Zippel <zippel@linux-m68k.org> writes: > > This explicitely defines 24 as DWARF_FRAME_RETURN_COLUMN for m68k and adds > > 25 as an alternative. IMO it's a bit unfortunate that these are > > automatically defined, as they have consequences for the exception ABI. > > Before this the return column was 25, but e.g. binutils uses 24 as return > > column and this wasn't recognized, so to unify this use 24 now (which > > nicely matches the arg pointer), but still accept 25. > > > > 2006-01-22 Roman Zippel <zippel@linux-m68k.org> > > > > * config/m68k/m68k.c (m68k_regno_mode_ok): return a valid size for > > the return column (which matches the argpointer) > > * config/m68k/m68k.h (DWARF_FRAME_REGISTERS,DWARF_FRAME_RETURN_COLUMN, > > DWARF_ALT_FRAME_RETURN_COLUMN): new macros > > (HARD_REGNO_NREGS): check upper limit for fp registers > > I'm a little suspicious about the way the patch is implemented. > It's effectively saying that ARG_POINTER_REGNUM is a real register > that holds the incoming return address. This isn't true on either > count. It isn't a real register, and it points at a stack slot that > contains the return address. We basically already told the exception code that arg ptr is a real register (although with unknown size), one function of this patch is to add a size to it. > Also, the documentation says: > > @defmac DWARF_ALT_FRAME_RETURN_COLUMN > A C expression whose value is an integer giving a DWARF 2 column > number that may be used as an alternate return column. This should > be defined only if @code{DWARF_FRAME_RETURN_COLUMN} is set to a > general register, but an alternate column needs to be used for > signal frames. > @end defmac It's says "should". :) If the patch is really that controversial, another alternative is to use only 24 as return column. I did this patch mainly for Debian, so it accepts both at runtime and if necessary it can be dropped after some time. > If I've understood correctly, the real problem here is that binutils has > used an undefined dwarf register (24) in its CIEs, and element 24 of the > dwarf register size table isn't set to sizeof (Pmode). Is that right? Yes, I have another patch for libffi, where I'm using it. > I think the > pedantically correct fix is to: > > (1) Extend the DWARF_ALT_FRAME_RETURN_COLUMN so that it can cope with > cases where (refering to dwarf2out.c) wrote_return_column is > false. I.e. allow ports to define two non-general "registers" > that can act as return address columns. Hmm, my patch basically does this. There may be a more correct way to fix this, but I'm a little reluctant, as I don't see a downside. > (2) Define the following: > > -------------------------------------------------------------------- > #define DWARF_FRAME_REGISTERS 25 > #define DWARF_FRAME_RETURN_COLUMN 24 > #define DWARF_ALT_FRAME_RETURN_COLUMN 25 > #define DWARF_FRAME_REGNUM(REG) \ > (INT_REGNO_P (REG) || FP_REGNO_P (REG) ? (REG) : -1) > -------------------------------------------------------------------- How would this initialize both slots of the size table? bye, Roman ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [m68k 1/2] define DWARF_FRAME_RETURN_COLUMN 2007-01-22 23:03 ` Roman Zippel @ 2007-01-23 7:55 ` Richard Sandiford 2007-01-23 11:52 ` Roman Zippel 0 siblings, 1 reply; 280+ messages in thread From: Richard Sandiford @ 2007-01-23 7:55 UTC (permalink / raw) To: Roman Zippel; +Cc: gcc-patches Roman Zippel <zippel@linux-m68k.org> writes: > If the patch is really that controversial, another alternative is to use > only 24 as return column. I did this patch mainly for Debian, so it > accepts both at runtime and if necessary it can be dropped after some > time. No, now I understand the history, I agree with the principle of allowing both registers 24 and 25. >> I think the >> pedantically correct fix is to: >> >> (1) Extend the DWARF_ALT_FRAME_RETURN_COLUMN so that it can cope with >> cases where (refering to dwarf2out.c) wrote_return_column is >> false. I.e. allow ports to define two non-general "registers" >> that can act as return address columns. > > Hmm, my patch basically does this. There may be a more correct way to fix > this, but I'm a little reluctant, as I don't see a downside. I don't follow. Your patch doesn't touch dwarf2out.c at all. The code reads: --------------------------------------------------------------------------- #ifdef DWARF_ALT_FRAME_RETURN_COLUMN gcc_assert (wrote_return_column); i = DWARF_ALT_FRAME_RETURN_COLUMN; wrote_return_column = false; #else i = DWARF_FRAME_RETURN_COLUMN; #endif if (! wrote_return_column) { enum machine_mode save_mode = Pmode; HOST_WIDE_INT offset = i * GET_MODE_SIZE (mode); HOST_WIDE_INT size = GET_MODE_SIZE (save_mode); emit_move_insn (adjust_address (mem, mode, offset), GEN_INT (size)); } --------------------------------------------------------------------------- So (as the documentation I quoted says), DWARF_ALT_FRAME_RETURN_COLUMN only works if DWARF_FRAME_RETURN_COLUMN is a general register; i.e. if DWARF_FRAME_REG(X) returns DWARF_FRAME_RETURN_COLUMN for some X in [0, FIRST_PSEUDO_REGISTER). You did that by pretending that ARG_POINTER_REGNUM is a general register, but it isn't. What I was suggesting in (1) was that we allow both DWARF_FRAME_RETURN_COLUMN _and_ DWARF_ALT_FRAME_RETURN_COLUMN to be non-general registers. I.e. to allow the case where you get neither from DWARF_FRAME_REGNUM. That would involve changes to dwarf2out.c, and a generalisation of the tm.texi documentation. The implementation is easy though; split the if (...) contents above into a separate function and do something on the lines of: --------------------------------------------------------------------------- if (!wrote_return_column) init_return_column_size (mem, DWARF_FRAME_RETURN_COLUMN); #ifdef DWARF_ALT_FRAME_RETURN_COLUMN init_return_column_size (mem, DWARF_ALT_FRAME_RETURN_COLUMN); #endif --------------------------------------------------------------------------- (Untested, but like I say, I'll code it up if there's agreement on the general approach.) >> (2) Define the following: >> >> -------------------------------------------------------------------- >> #define DWARF_FRAME_REGISTERS 25 >> #define DWARF_FRAME_RETURN_COLUMN 24 >> #define DWARF_ALT_FRAME_RETURN_COLUMN 25 >> #define DWARF_FRAME_REGNUM(REG) \ >> (INT_REGNO_P (REG) || FP_REGNO_P (REG) ? (REG) : -1) >> -------------------------------------------------------------------- > > How would this initialize both slots of the size table? See above. Richard ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [m68k 1/2] define DWARF_FRAME_RETURN_COLUMN 2007-01-23 7:55 ` Richard Sandiford @ 2007-01-23 11:52 ` Roman Zippel 2007-01-29 10:38 ` Richard Sandiford 0 siblings, 1 reply; 280+ messages in thread From: Roman Zippel @ 2007-01-23 11:52 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches Hi, On Tue, 23 Jan 2007, Richard Sandiford wrote: > I don't follow. Your patch doesn't touch dwarf2out.c at all. Indeed, that's what I wanted to avoid. > So (as the documentation I quoted says), DWARF_ALT_FRAME_RETURN_COLUMN > only works if DWARF_FRAME_RETURN_COLUMN is a general register; i.e. if > DWARF_FRAME_REG(X) returns DWARF_FRAME_RETURN_COLUMN for some X in > [0, FIRST_PSEUDO_REGISTER). You did that by pretending that > ARG_POINTER_REGNUM is a general register, but it isn't. It's fixed, so I don't see a big problem with that. > What I was suggesting in (1) was that we allow both > DWARF_FRAME_RETURN_COLUMN _and_ DWARF_ALT_FRAME_RETURN_COLUMN > to be non-general registers. I.e. to allow the case where > you get neither from DWARF_FRAME_REGNUM. That would involve > changes to dwarf2out.c, and a generalisation of the tm.texi > documentation. The implementation is easy though; split the > if (...) contents above into a separate function and do > something on the lines of: > > --------------------------------------------------------------------------- > if (!wrote_return_column) > init_return_column_size (mem, DWARF_FRAME_RETURN_COLUMN); > > #ifdef DWARF_ALT_FRAME_RETURN_COLUMN > init_return_column_size (mem, DWARF_ALT_FRAME_RETURN_COLUMN); > #endif > --------------------------------------------------------------------------- > > (Untested, but like I say, I'll code it up if there's agreement > on the general approach.) Well, I was aiming at a less invasive approach, but in the end that's fine with me too. bye, Roman ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [m68k 1/2] define DWARF_FRAME_RETURN_COLUMN 2007-01-23 11:52 ` Roman Zippel @ 2007-01-29 10:38 ` Richard Sandiford 2007-01-31 22:34 ` Andreas Schwab 0 siblings, 1 reply; 280+ messages in thread From: Richard Sandiford @ 2007-01-29 10:38 UTC (permalink / raw) To: Roman Zippel; +Cc: gcc-patches Roman Zippel <zippel@linux-m68k.org> writes: > On Tue, 23 Jan 2007, Richard Sandiford wrote: >> What I was suggesting in (1) was that we allow both >> DWARF_FRAME_RETURN_COLUMN _and_ DWARF_ALT_FRAME_RETURN_COLUMN >> to be non-general registers. I.e. to allow the case where >> you get neither from DWARF_FRAME_REGNUM. That would involve >> changes to dwarf2out.c, and a generalisation of the tm.texi >> documentation. The implementation is easy though; split the >> if (...) contents above into a separate function and do >> something on the lines of: >> >> --------------------------------------------------------------------------- >> if (!wrote_return_column) >> init_return_column_size (mem, DWARF_FRAME_RETURN_COLUMN); >> >> #ifdef DWARF_ALT_FRAME_RETURN_COLUMN >> init_return_column_size (mem, DWARF_ALT_FRAME_RETURN_COLUMN); >> #endif >> --------------------------------------------------------------------------- >> >> (Untested, but like I say, I'll code it up if there's agreement >> on the general approach.) > > Well, I was aiming at a less invasive approach, but in the end that's fine > with me too. OK, there didn't seem to be any objections, so here's the patch. Tested on m68k-linux-gnu. OK to install? Richard gcc/ * doc/tm.texi (DWARF_ALT_FRAME_RETURN_COLUMN): Do not require DWARF_FRAME_RETURN_COLUMN to be a general register. * dwarf2out.c (init_return_column_size): New function, split from... (expand_builtin_init_dwarf_reg_sizes): ...here. Allow both DWARF_FRAME_RETURN_COLUMN and DWARF_ALT_FRAME_RETURN_COLUMN to be nongeneral registers. * config/m68k/m68k.h (DWARF_FRAME_REGNUM): Only map FP and integer registers. (DWARF_FRAME_REGISTERS, DWARF_FRAME_RETURN_COLUMN): Define. (DWARF_ALT_FRAME_RETURN_COLUMN): Define. Index: gcc/doc/tm.texi =================================================================== --- gcc/doc/tm.texi 2007-01-25 07:20:12.611850000 -0800 +++ gcc/doc/tm.texi 2007-01-29 02:36:11.735701000 -0800 @@ -3107,10 +3107,14 @@ If this RTL is a @code{REG}, you should @defmac DWARF_ALT_FRAME_RETURN_COLUMN A C expression whose value is an integer giving a DWARF 2 column -number that may be used as an alternate return column. This should -be defined only if @code{DWARF_FRAME_RETURN_COLUMN} is set to a -general register, but an alternate column needs to be used for -signal frames. +number that may be used as an alternative return column. The column +must not correspond to any gcc hard register (that is, it must not +be in the range of @code{DWARF_FRAME_REGNUM}). + +This macro can be useful if @code{DWARF_FRAME_RETURN_COLUMN} is set to a +general register, but an alternative column needs to be used for signal +frames. Some targets have also used different frame return columns +over time. @end defmac @defmac DWARF_ZERO_REG Index: gcc/dwarf2out.c =================================================================== --- gcc/dwarf2out.c 2007-01-25 07:20:12.742146000 -0800 +++ gcc/dwarf2out.c 2007-01-29 02:26:14.255956000 -0800 @@ -443,6 +443,17 @@ stripattributes (const char *s) return stripped; } +/* MEM is a memory reference for the register size table, each element of + which has mode MODE. Initialize column C as a return address column. */ + +static void +init_return_column_size (enum machine_mode mode, rtx mem, unsigned int c) +{ + HOST_WIDE_INT offset = c * GET_MODE_SIZE (mode); + HOST_WIDE_INT size = GET_MODE_SIZE (Pmode); + emit_move_insn (adjust_address (mem, mode, offset), GEN_INT (size)); +} + /* Generate code to initialize the register size table. */ void @@ -481,21 +492,12 @@ expand_builtin_init_dwarf_reg_sizes (tre } } + if (!wrote_return_column) + init_return_column_size (mode, mem, DWARF_FRAME_RETURN_COLUMN); + #ifdef DWARF_ALT_FRAME_RETURN_COLUMN - gcc_assert (wrote_return_column); - i = DWARF_ALT_FRAME_RETURN_COLUMN; - wrote_return_column = false; -#else - i = DWARF_FRAME_RETURN_COLUMN; + init_return_column_size (mode, mem, DWARF_ALT_FRAME_RETURN_COLUMN); #endif - - if (! wrote_return_column) - { - enum machine_mode save_mode = Pmode; - HOST_WIDE_INT offset = i * GET_MODE_SIZE (mode); - HOST_WIDE_INT size = GET_MODE_SIZE (save_mode); - emit_move_insn (adjust_address (mem, mode, offset), GEN_INT (size)); - } } /* Convert a DWARF call frame info. operation to its string name */ Index: gcc/config/m68k/m68k.h =================================================================== --- gcc/config/m68k/m68k.h 2007-01-25 07:21:34.696470000 -0800 +++ gcc/config/m68k/m68k.h 2007-01-25 07:21:36.292089000 -0800 @@ -955,7 +955,15 @@ #define RETURN_ADDR_RTX(COUNT, FRAME) /* We must not use the DBX register numbers for the DWARF 2 CFA column numbers because that maps to numbers beyond FIRST_PSEUDO_REGISTER. Instead use the identity mapping. */ -#define DWARF_FRAME_REGNUM(REG) REG +#define DWARF_FRAME_REGNUM(REG) \ + (INT_REGNO_P (REG) || FP_REGNO_P (REG) ? (REG) : INVALID_REGNUM) + +/* The return column was originally 24, but gcc used 25 for a while too. + Define both registers 24 and 25 as Pmode ones and use 24 in our own + unwind information. */ +#define DWARF_FRAME_REGISTERS 25 +#define DWARF_FRAME_RETURN_COLUMN 24 +#define DWARF_ALT_FRAME_RETURN_COLUMN 25 /* Before the prologue, the top of the frame is at 4(%sp). */ #define INCOMING_FRAME_SP_OFFSET 4 ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [m68k 1/2] define DWARF_FRAME_RETURN_COLUMN 2007-01-29 10:38 ` Richard Sandiford @ 2007-01-31 22:34 ` Andreas Schwab 0 siblings, 0 replies; 280+ messages in thread From: Andreas Schwab @ 2007-01-31 22:34 UTC (permalink / raw) To: richard; +Cc: gcc-patches, Roman Zippel Richard Sandiford <richard@codesourcery.com> writes: > gcc/ > * doc/tm.texi (DWARF_ALT_FRAME_RETURN_COLUMN): Do not require > DWARF_FRAME_RETURN_COLUMN to be a general register. > * dwarf2out.c (init_return_column_size): New function, split from... > (expand_builtin_init_dwarf_reg_sizes): ...here. Allow both > DWARF_FRAME_RETURN_COLUMN and DWARF_ALT_FRAME_RETURN_COLUMN > to be nongeneral registers. > * config/m68k/m68k.h (DWARF_FRAME_REGNUM): Only map FP and > integer registers. > (DWARF_FRAME_REGISTERS, DWARF_FRAME_RETURN_COLUMN): Define. > (DWARF_ALT_FRAME_RETURN_COLUMN): Define. The m68k parts are ok. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 45/63] Set TARGET_ASM_FILE_START_APP_OFF to false for GNU/Linux 2007-01-10 12:00 ` [ColdFire 45/63] Set TARGET_ASM_FILE_START_APP_OFF to false for GNU/Linux Richard Sandiford 2007-01-10 12:01 ` [ColdFire 46/63] Add support for unwinding through signal handlers Richard Sandiford @ 2007-01-10 17:59 ` Jeffrey Law 2007-01-10 18:28 ` Andreas Schwab 2 siblings, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-01-10 17:59 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches On Wed, 2007-01-10 at 12:00 +0000, Richard Sandiford wrote: > The m68k port defaults to "# APP OFF". However, it can't compile glibc > in that state, because glibc uses comments to hide section attributes. > > TARGET_ASM_FILE_START_APP_OFF is already an OS-style target hook -- > the default is protected by an #ifdef guard -- so this patch simply > moves the m68k definition from m68k.c to m68k.h and overrides it > in linux.h. > > Richard > > > gcc/ > * config/m68k/m68k.h (TARGET_ASM_FILE_START_APP_OFF): Define. > * config/m68k/linux.h (TARGET_ASM_FILE_START_APP_OFF): Override. > * config/m68k/m68k.c (TARGET_ASM_FILE_START_APP_OFF): Delete. OK. Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 45/63] Set TARGET_ASM_FILE_START_APP_OFF to false for GNU/Linux 2007-01-10 12:00 ` [ColdFire 45/63] Set TARGET_ASM_FILE_START_APP_OFF to false for GNU/Linux Richard Sandiford 2007-01-10 12:01 ` [ColdFire 46/63] Add support for unwinding through signal handlers Richard Sandiford 2007-01-10 17:59 ` [ColdFire 45/63] Set TARGET_ASM_FILE_START_APP_OFF to false for GNU/Linux Jeffrey Law @ 2007-01-10 18:28 ` Andreas Schwab 2007-01-10 18:43 ` Jeffrey Law 2 siblings, 1 reply; 280+ messages in thread From: Andreas Schwab @ 2007-01-10 18:28 UTC (permalink / raw) To: gcc-patches; +Cc: richard Richard Sandiford <richard@codesourcery.com> writes: > The m68k port defaults to "# APP OFF". However, it can't compile glibc > in that state, because glibc uses comments to hide section attributes. This is no longer true with current bintuils. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 45/63] Set TARGET_ASM_FILE_START_APP_OFF to false for GNU/Linux 2007-01-10 18:28 ` Andreas Schwab @ 2007-01-10 18:43 ` Jeffrey Law 2007-01-10 18:50 ` Andreas Schwab 0 siblings, 1 reply; 280+ messages in thread From: Jeffrey Law @ 2007-01-10 18:43 UTC (permalink / raw) To: Andreas Schwab; +Cc: gcc-patches, richard On Wed, 2007-01-10 at 19:27 +0100, Andreas Schwab wrote: > Richard Sandiford <richard@codesourcery.com> writes: > > > The m68k port defaults to "# APP OFF". However, it can't compile glibc > > in that state, because glibc uses comments to hide section attributes. > > This is no longer true with current bintuils. But do we always know we're using the latest stuff? jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 45/63] Set TARGET_ASM_FILE_START_APP_OFF to false for GNU/Linux 2007-01-10 18:43 ` Jeffrey Law @ 2007-01-10 18:50 ` Andreas Schwab 2007-01-10 19:15 ` Jeffrey Law 0 siblings, 1 reply; 280+ messages in thread From: Andreas Schwab @ 2007-01-10 18:50 UTC (permalink / raw) To: law; +Cc: gcc-patches, richard Jeffrey Law <law@redhat.com> writes: > On Wed, 2007-01-10 at 19:27 +0100, Andreas Schwab wrote: >> Richard Sandiford <richard@codesourcery.com> writes: >> >> > The m68k port defaults to "# APP OFF". However, it can't compile glibc >> > in that state, because glibc uses comments to hide section attributes. >> >> This is no longer true with current bintuils. > But do we always know we're using the latest stuff? That should rather be a question for glibc. I don't think the compiler should care at this point. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 45/63] Set TARGET_ASM_FILE_START_APP_OFF to false for GNU/Linux 2007-01-10 18:50 ` Andreas Schwab @ 2007-01-10 19:15 ` Jeffrey Law 2007-01-10 19:45 ` Andreas Schwab 0 siblings, 1 reply; 280+ messages in thread From: Jeffrey Law @ 2007-01-10 19:15 UTC (permalink / raw) To: Andreas Schwab; +Cc: gcc-patches, richard On Wed, 2007-01-10 at 19:50 +0100, Andreas Schwab wrote: > Jeffrey Law <law@redhat.com> writes: > > > On Wed, 2007-01-10 at 19:27 +0100, Andreas Schwab wrote: > >> Richard Sandiford <richard@codesourcery.com> writes: > >> > >> > The m68k port defaults to "# APP OFF". However, it can't compile glibc > >> > in that state, because glibc uses comments to hide section attributes. > >> > >> This is no longer true with current bintuils. > > But do we always know we're using the latest stuff? > > That should rather be a question for glibc. I don't think the compiler > should care at this point. I don't follow, but perhaps I'm missing something. If I understand the issue correctly, glibc uses comments to hide section attributes (as could other code). This makes it impossible for GCC to compile glibc without #APP OFF. You then said that this is no longer true with the current binutils (?). If binutils is what's making it possible to compile glibc without #APP OFF, then this is a feature of the new binutils, not a glibc issue. If this is a feature of the new binutils, then we need to either test for that or continue to use #APP OFF. What am I missing? jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 45/63] Set TARGET_ASM_FILE_START_APP_OFF to false for GNU/Linux 2007-01-10 19:15 ` Jeffrey Law @ 2007-01-10 19:45 ` Andreas Schwab 0 siblings, 0 replies; 280+ messages in thread From: Andreas Schwab @ 2007-01-10 19:45 UTC (permalink / raw) To: law; +Cc: gcc-patches, richard Jeffrey Law <law@redhat.com> writes: > If I understand the issue correctly, glibc uses comments to hide section > attributes (as could other code). It uses a form of comments that depend on being recongnized in the middle of the line (comments are always recongnized at the start of the line, independent of #APP). That could have been fixed in glibc, but the glibc maintainer is known to not care about such things. > This makes it impossible for GCC to compile glibc without #APP OFF. It produces an error with a certain version of binutils. Both older and newer versions work. > You then said that this is no longer true with the current binutils (?). Right. GAS has been changed to allow this (IMHO questional) use inside of glibc again. > If binutils is what's making it possible to compile glibc without > #APP OFF, then this is a feature of the new binutils, not a glibc issue. Right. But it's glibc that is using a not really supported construct that just happend to work with old binutils, or with #APP. > If this is a feature of the new binutils, then we need to either test > for that or continue to use #APP OFF. It is a failure of glibc that is uses a form of comment that is not really supported by GAS outside #APP, and happened to be broken in one version. I would like to retain #NO_APP since it is a noticable performance increase when running the assembler natively. Nothing of this mess is a fault of the compiler, IMHO. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 44/63] Remove unncessary saves and restores of %a5 2007-01-10 11:58 ` [ColdFire 44/63] Remove unncessary saves and restores of %a5 Richard Sandiford 2007-01-10 12:00 ` [ColdFire 45/63] Set TARGET_ASM_FILE_START_APP_OFF to false for GNU/Linux Richard Sandiford @ 2007-01-11 17:50 ` Jeffrey Law 1 sibling, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-01-11 17:50 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches On Wed, 2007-01-10 at 11:58 +0000, Richard Sandiford wrote: > As mentioned previously, there is code to make sure that the PIC > register is always saved and restored by nonleaf functions if > TARGET_ID_SHARED_LIBRARY. This special case is no longer needed > because the GOT loads have been separated out from the call patterns. > > Richard > > > gcc/ > * config/m68k/m68k.c (m68k_save_reg): Remove special case for > leaf functions. > (m68k_expand_prologue): Likewise. OK. Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 43/63] Use floating-point branches on ColdFire too 2007-01-10 11:57 ` [ColdFire 43/63] Use floating-point branches on ColdFire too Richard Sandiford 2007-01-10 11:58 ` [ColdFire 44/63] Remove unncessary saves and restores of %a5 Richard Sandiford @ 2007-01-10 17:58 ` Jeffrey Law 1 sibling, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-01-10 17:58 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches On Wed, 2007-01-10 at 11:57 +0000, Richard Sandiford wrote: > The 68881 FPU branches apply equally well to the ColdFire FPU, so this > patch changes the condition from TARGET_68881 to TARGET_HARD_FLOAT. > > Richard > > > gcc/ > * config/m68k/m68k.md (bordered, bunordered, buneq, bunge, bungt) > (bunle, bunlt, bltgt, bordered_rev, bunordered_rev, buneq_rev) > (bunge_rev, bungt_rev, bunle_rev, bunlt_rev, bltgt_rev): Change > condition from TARGET_68881 to TARGET_HARD_FLOAT. OK. jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 42/63] Add support for sibling calls 2007-01-10 11:56 ` [ColdFire 42/63] Add support for sibling calls Richard Sandiford 2007-01-10 11:57 ` [ColdFire 43/63] Use floating-point branches on ColdFire too Richard Sandiford @ 2007-01-16 18:04 ` Jeffrey Law 1 sibling, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-01-16 18:04 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches On Wed, 2007-01-10 at 11:56 +0000, Richard Sandiford wrote: > This patch adds support for sibcalls. It's a useful optimisation in its > own right, but it's also needed by the upcoming thunks patch. > > Indirect sibcalls must use a register that isn't clobbered by the > epilogue, and that isn't live on entry to the callee. The patch uses > the static chain register for this purpose and forbids sibcalls to > functions that need a static chain register. > > The sibcall_operand predicate only allows valid constants and the > static chain register. The operand therefore doesn't need to be > (and shouldn't be) reloaded, so the patch uses empty constraints. > This seems better than adding a special register class. > > Richard > > > gcc/ > * config/m68k/m68k-protos.h (output_sibcall): Declare. > (mips_expand_epilogue): Add a bool parameter. > (m68k_legitimize_sibcall_address): Declare. > * config/m68k/m68k.c (TARGET_FUNCTION_OK_FOR_SIBCALL): Define. > (m68k_expand_epilogue): Add a parameter to select between sibling > and normal epilogues. Only generate a return for the latter. > (m68k_ok_for_sibcall_p): New function. > (m68k_legitimize_sibcall_address, output_sibcall): New functions. > * config/m68k/m68k.md (sibcall, *sibcall): New patterns. > (sibcall_value, *sibcall_value): Likewise. > (*call, *call_value): Require !SIBLING_CALL_P. > (epilogue): Update call to m68k_expand_epilogue. > (sibcall_epilogue): New pattern. > * config/m68k/predicates.md (const_call_operand): Say that this > predicate applies to sibling calls too. > (sibcall_operand): New predicate. OK. jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 41/63] Add support for the ff1 instruction 2007-01-10 11:55 ` [ColdFire 41/63] Add support for the ff1 instruction Richard Sandiford 2007-01-10 11:56 ` [ColdFire 42/63] Add support for sibling calls Richard Sandiford @ 2007-01-10 19:21 ` Jeffrey Law 1 sibling, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-01-10 19:21 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches On Wed, 2007-01-10 at 11:55 +0000, Richard Sandiford wrote: > This patch adds support for the ISA A+ and ISA C ff1 instruction. > > Richard > > > gcc/ > 200x-xx-xx Sandra Loosemore <sandra@codesourcery.com> > > * longlong.h (count_leading_zeros, COUNT_LEADING_ZEROS_0): Add > ColdFire alternatives. > * config/m68k/m68k.h (CLZ_DEFINED_VALUE_AT_ZERO): New macro. > * config/m68k/m68k.md (clzsi2): Define for ColdFire > architectures that support ff1 instruction. OK. Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 40/63] Add more movsf_cf_soft alternatives 2007-01-10 11:55 ` [ColdFire 40/63] Add more movsf_cf_soft alternatives Richard Sandiford 2007-01-10 11:55 ` [ColdFire 41/63] Add support for the ff1 instruction Richard Sandiford @ 2007-01-10 18:46 ` Jeffrey Law 1 sibling, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-01-10 18:46 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches On Wed, 2007-01-10 at 11:55 +0000, Richard Sandiford wrote: > The movsf_cf_soft constraints reject some operand combinations that > are supported by the underlying instructions. This patch fixes that. > The post-patch constraints are the same as those in the equivalent > SImode patterns, minus the use of mov3q constants. > > Richard > > > gcc/ > * config/m68k/m68k.md (movsf_cf_soft): Provide the same non-mov3q > alternatives as movsi_cf. > (movsf_cf_hard): Add commentary. OK. Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 39/63] Fix mov3q handling 2007-01-10 11:53 ` [ColdFire 39/63] Fix mov3q handling Richard Sandiford 2007-01-10 11:55 ` [ColdFire 40/63] Add more movsf_cf_soft alternatives Richard Sandiford @ 2007-01-10 18:46 ` Jeffrey Law 1 sibling, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-01-10 18:46 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches On Wed, 2007-01-10 at 11:53 +0000, Richard Sandiford wrote: > m68k.md has a separate *movsi_cfv4 pattern that differs *movsi_cf > only in the addition of 'R' constraints. It seems fairly obvious > from context that 'R' was supposed to be a mov3q constant, but > nothing actually defines it. > > This patch maps 'R' to valid_mov3q_const. Because valid_mov3q_const > checks the architecture itself, there's no need for a separate pattern; > we can use the *movsi_cfv4 form for other ColdFire targets too. > Also, the 'R' in the first *movsi_cfv4 alternative is redundant, > as 'R' implies 'g'. > > Richard > > > gcc/ > 200x-xx-xx Richard Sandiford <richard@codesourcery.com> > Julian Brown <julian@codesourcery.com> > > * config/m68k/m68k.h (CONST_OK_FOR_LETTER_P): Add an 'R' case. > * config/m68k/m68k.md (*movsi_cfv4): Fold into... > (*movsi_cf): ...here. Remove unnecessary 'R' from 'Rg'. > Add commentary. OK. Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 38/63] Clean up handling of integer moves 2007-01-10 11:51 ` [ColdFire 38/63] Clean up handling of integer moves Richard Sandiford 2007-01-10 11:53 ` [ColdFire 39/63] Fix mov3q handling Richard Sandiford @ 2007-01-16 17:49 ` Jeffrey Law 1 sibling, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-01-16 17:49 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches On Wed, 2007-01-10 at 11:51 +0000, Richard Sandiford wrote: > This patch makes various constant-related functions take a > HOST_WIDE_INT rather than a CONST_INT rtx. It's partly a cleanup, > but the valid_mov3q_const part is also needed by the next patch. > > Richard > > > gcc/ > * config/m68k/m68k-protos.h (valid_mov3q_const): Take a HOST_WIDE_INT > and return a bool. > (output_move_const_into_data_reg, output_move_simode_const): Delete. > * config/m68k/m68k.c (const_method, const_int_cost): Take a > HOST_WIDE_INT instead of an rtx. > (m68k_rtx_costs): Update call accordingly. > (output_move_const_into_data_reg): Likewise. Fix formatting. > (valid_mov3q_const): Take a HOST_WIDE_INT instead of an rtx. > Return a bool. > (output_move_simode_const): Update calls after above changes. > Rework to use automatic variables and predicates like MEM_P. > * config/m68k/m68k.md (pushexthisi_const): Update call to > valid_mov3q_const. OK. I should have worked through the dependency chain earlier (I think I approved a later patch which depends on this one). Sorry about that. Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 37/63] Use RTL for prologues and epilogues 2007-01-10 11:50 ` [ColdFire 37/63] " Richard Sandiford 2007-01-10 11:51 ` [ColdFire 38/63] Clean up handling of integer moves Richard Sandiford @ 2007-01-16 17:58 ` Jeffrey Law 1 sibling, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-01-16 17:58 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches On Wed, 2007-01-10 at 11:50 +0000, Richard Sandiford wrote: > This patch is an update of: > > http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01366.html > > see there for rationale. The changes from the original patch > are as follows: > > - It uses new predicates rather than separate HARD_FP_REG_P > checks to request a particular type of register. > > - It avoids hard-coding (mem: ...)s into the output pattern > as these MEMs will have no aliasing information. (This would > become important if we added scheduling descriptions later on.) > Instead, it generates new forms of the original MEMs. > > - It stops the peepholes from emitting an addition of 0. > > - The current QImode peepholes use: > > [(set (mem:QI (pre_dec:SI (reg:SI SP_REG))) > (match_operand:QI 0 "..." "")) > (set (reg:SI SP_REG) (minus:SI (reg:SI SP_REG) (const_int 2)))] > > but given that we're generating an SImode access, I'm sure that > that 2 was meant to be a 3. The pattern should never match > anyway because (minus ... (const_int ..)) isn't canonical. > The patch fixes both problems. > > - The register form of the QImode peephole is a win on Coldfire > too, so the patch continues to allow it there. > > Richard > > > gcc/ > 200x-xx-xx Paul Brook <paul@codesourcery.com> > Richard Sandiford <richard@codesourcery.com> > > * config/m68k/predicates.md (integer_register): New predicate. > (float_register): Likewise. > * config/m68k/m68k.md (UNSPEC_MOVEQ_MEM): New constant. > (*movsi_smallconst): New pattern. > Convert the first define_peephole to a define_peephole2. Use > float_register and integer_register than than separate REGNO > checks. Convert the second and third define_peepholes to > define_peephole2s. Convert the fourth define_peephole into two > separate define_peephole2s, one for register sources and one for > other types of source. Fix the size of the separate stack > adjustment and expect it to be a PLUS of a negative constant > rather than a MINUS of a positive constant. OK. Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 36/63] Use RTL for prologues and epilogues 2007-01-10 11:49 ` [ColdFire 36/63] Use RTL for prologues and epilogues Richard Sandiford 2007-01-10 11:50 ` [ColdFire 37/63] " Richard Sandiford @ 2007-01-10 23:06 ` Joseph S. Myers 2007-01-11 8:10 ` Richard Sandiford 2007-01-16 17:53 ` Jeffrey Law 2007-01-22 18:11 ` Roman Zippel 3 siblings, 1 reply; 280+ messages in thread From: Joseph S. Myers @ 2007-01-10 23:06 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches I think this may need an update to backends.html which tracks various features such as which targets use RTL prologues and epilogues. -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 36/63] Use RTL for prologues and epilogues 2007-01-10 23:06 ` [ColdFire 36/63] " Joseph S. Myers @ 2007-01-11 8:10 ` Richard Sandiford 0 siblings, 0 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-11 8:10 UTC (permalink / raw) To: Joseph S. Myers; +Cc: gcc-patches "Joseph S. Myers" <joseph@codesourcery.com> writes: > I think this may need an update to backends.html which tracks various > features such as which targets use RTL prologues and epilogues. Good point. I'll make a note to do that when the patch goes in. Richard ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 36/63] Use RTL for prologues and epilogues 2007-01-10 11:49 ` [ColdFire 36/63] Use RTL for prologues and epilogues Richard Sandiford 2007-01-10 11:50 ` [ColdFire 37/63] " Richard Sandiford 2007-01-10 23:06 ` [ColdFire 36/63] " Joseph S. Myers @ 2007-01-16 17:53 ` Jeffrey Law 2007-01-16 17:56 ` Richard Sandiford 2007-01-22 18:11 ` Roman Zippel 3 siblings, 1 reply; 280+ messages in thread From: Jeffrey Law @ 2007-01-16 17:53 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches On Wed, 2007-01-10 at 11:48 +0000, Richard Sandiford wrote: > This patch converts the prologue and epilogue code to use "prologue" > and "epilogue" rtl expanders. It improves the debuggability of > prologues and epilogues and paves the way for scheduling them > in future (if any m68k schedulers are added). > > The patch tries to preserve the existing code-generation decisions where > possible. However, gcc.c-torture/execute/921113-1.c showed up a bug in > the old handling of big stack frames on ColdFire. If the frame is so > big that the saved registers cannot be reached from %fp using 16-bit > offsets, the 680x0 epilogue code will load the frame size into %a1 and > use accesses of the form (d8,%fp,%a1). ColdFire can do the same when > restoring registers individually, but unfortunately, the ColdFire movems > don't support (d8,%fp,%a1). We therefore have to add %fp to %a1 and use > the new %a1 as a base address in the movems. > > This new %a1 is used for both general register restores (movem) and > floating-point restores (fmovem). The problem is that the add is part > of the movem code, and that code is only needed when restoring 3 or > more general registers. In other cases, floating-point restores will > be from the unmodified %a1 (i.e. "-framesize"). > > Also, we have: > > /* Because the ColdFire doesn't support moveml with > complex address modes we make an extra correction here. */ > if (m68k_arch_coldfire) > fsize += current_frame.offset; > > But this is wrong when restoring registers individually. The code > to restore individual registers assumes that %a1 contains -fsize, > not -(fsize + current_frame.offset). > > Making the current scheme work would mean adding yet more rarely-used > special cases. I don't think that's a good solution. Given the > addressing-mode restrictions, I think the best fix is to simply use > a stack-based restore for big ColdFire frames if we need to use movem > or fmovem. In other words, we set %sp from %fp in that case. > > The new lea is two bytes longer than the old add, so this makes > the epilogue 2 bytes longer for the case that previously worked > (i.e. 3 or more general registers restored, no FP registers stored). > The upside is that we can now use plain (%sp)+ addresses when restoring > 1 or 2 general registers. We can also use (%sp) for fmovem when > restoring 0, 1 or 2 general registers. > > Richard > > > gcc/ > 200x-xx-xx Kazu Hirata <kazu@codesourcery.com> > Richard Sandiford <richard@codesourcery.com> > > * config/m68k/m68k-protos.h (m68k_interrupt_function_p): Declare. > (m68k_movem_pattern_p, m68k_output_movem): Likewise. > (m68k_expand_prologue, m68k_expand_epilogue): Likewise. > * config/m68k/m68k.h (EPILOGUE_USES): Define. Treat all registers > as being live on exit from an interrupt function. > (PRINT_OPERAND_PUNCT_VALID_P): Return true for '?'. > * config/m68k/m68k.c (MIN_MOVEM_REGS, MIN_FMOVEM_REGS): New macros. > (m68k_frame): Remove reg_rev_mask and fpu_rev_mask. > (TARGET_ASM_FUNCTION_PROLOGUE, TARGET_ASM_FUNCTION_EPILOGUE): Delete. > (m68k_interrupt_function_p): Globalize. > (m68k_compute_frame_layout): Remove reverse mask code. > (m68k_emit_movem, m68k_set_frame_related): New functions. > (m68k_output_function_prologue): Delete in favor of... > (m68k_expand_prologue): ...this new function. > (m68k_output_function_epilogue): Delete in favor of... > (m68k_expand_epilogue): ...this new function. > (m68k_split_offset, m68k_movem_pattern_p, m68k_output_movem): New > functions. > (print_operand): Handle %?. > * config/m68k/m68k.md (UNSPEC_SIN, UNSPEC_COS): Remove excess space. > (UNSPEC_GOT, A1_REG, PIC_REG, FP0_REG): New constants. > (prologue, epilogue): New patterns. > (return): Turn into a define_expand. > (*return): New pattern, derived from old "return" pattern. Use rte > rather than rts for interrupt functions. Only use rtd if the pop > count is nonzero. > (*m68k_store_multiple, *m68k_store_multiple_automod): New patterns. > (*m68k_load_multiple, *m68k_load_multiple_automod): Likewise. > (link, *link, unlink, *unlink, load_got): Likewise. OK. I haven't audited this with a fine tooth comb; removing the textual prologues/epilogues is clearly a good thing and I'm willing to take the chance of a little fallout if there's a buglet or two and that you'll address any problems that arise. Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 36/63] Use RTL for prologues and epilogues 2007-01-16 17:53 ` Jeffrey Law @ 2007-01-16 17:56 ` Richard Sandiford 0 siblings, 0 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-16 17:56 UTC (permalink / raw) To: law; +Cc: gcc-patches Jeffrey Law <law@redhat.com> writes: > OK. I haven't audited this with a fine tooth comb; removing > the textual prologues/epilogues is clearly a good thing and > I'm willing to take the chance of a little fallout if there's > a buglet or two and that you'll address any problems that arise. Thanks. Like you say, I'm definitely on the hook to fix fallout from this patch, so anyone please cc: me on bug reports, etc. Richard ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 36/63] Use RTL for prologues and epilogues 2007-01-10 11:49 ` [ColdFire 36/63] Use RTL for prologues and epilogues Richard Sandiford ` (2 preceding siblings ...) 2007-01-16 17:53 ` Jeffrey Law @ 2007-01-22 18:11 ` Roman Zippel 2007-01-22 20:07 ` Richard Sandiford 3 siblings, 1 reply; 280+ messages in thread From: Roman Zippel @ 2007-01-22 18:11 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches Hi, On Wed, 10 Jan 2007, Richard Sandiford wrote: > ! /* Emit RTL for a MOVEM or FMOVEM instruction. BASE + OFFSET represents > ! the lowest memory address. COUNT is the number of registers to be > ! moved, with register REGNO + I being moved if bit I of MASK is set. > ! STORE_P specifies the direction of the move and ADJUST_STACK_P says > ! whether or not this is pre-decrement (if STORE_P) or post-increment > ! (if !STORE_P) operation. */ > ! > ! static rtx > ! m68k_emit_movem (rtx base, HOST_WIDE_INT offset, > ! unsigned int count, unsigned int regno, > ! unsigned int mask, bool store_p, bool adjust_stack_p) > ! { > ! int i; > ! rtx body, addr, src, operands[2]; > ! enum machine_mode mode; > ! > ! body = gen_rtx_PARALLEL (VOIDmode, rtvec_alloc (adjust_stack_p + count)); > ! mode = reg_raw_mode[regno]; > ! i = 0; > ! > ! if (adjust_stack_p) > ! { > ! src = plus_constant (base, (count > ! * GET_MODE_SIZE (mode) > ! * (HOST_WIDE_INT) (store_p ? -1 : 1))); > ! XVECEXP (body, 0, i++) = gen_rtx_SET (VOIDmode, base, src); > ! } Unless something changed recently, this won't work. Although this is a parallel, the parser for the frame information scans and executes this serially and all following stack assignments would get a wrong offset. The parser could be fixed, but the simpler fix is to just put this at the end. > ! (define_insn "*m68k_store_multiple_automod" > ! [(match_parallel 0 "" > ! [(set (match_operand:SI 1 "register_operand" "=a") > ! (plus:SI (match_operand:SI 2 "register_operand" "1") > ! (match_operand:SI 3 "const_int_operand")))])] > ! "m68k_movem_pattern_p (operands[0], operands[1], INTVAL (operands[3]), true)" > ! { > ! return m68k_output_movem (operands, operands[0], INTVAL (operands[3]), true); > ! }) I have a different version of this patch (which unfortunately had a few pieces missing, so I never submitted it), which does this: (define_insn "*moveml_store" [(match_parallel 0 "movem_operation" [(unspec:SI [(match_operand:SI 1 "const_int_operand" "i") (match_operand:BLK 2 "memory_operand" "=m")] UNSPEC_MOVEM) (set (match_operand:SI 3 "memory_operand" "=g") (match_operand:SI 4 "register_operand" "r"))])] "" "movem%.l %1,%2") This means it uses a unspec for instruction parameter and I'm also considering to move the rest of the pattern into a frame related note, so the big m68k_movem_pattern_p/m68k_output_movem functions become unneccessary. Anyway, unless you badly want to do these changes yourself, it's fine with me to commit this as is and I'll submit a cleanup patch later, once I have tested it fully with all your other changes on m68k hardware. bye, Roman ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 36/63] Use RTL for prologues and epilogues 2007-01-22 18:11 ` Roman Zippel @ 2007-01-22 20:07 ` Richard Sandiford 2007-01-23 1:05 ` Roman Zippel 2007-01-29 10:23 ` Improve PARALLEL handling in dwarf2out_frame_debug_expr Richard Sandiford 0 siblings, 2 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-22 20:07 UTC (permalink / raw) To: Roman Zippel; +Cc: gcc-patches Roman Zippel <zippel@linux-m68k.org> writes: > On Wed, 10 Jan 2007, Richard Sandiford wrote: >> ! /* Emit RTL for a MOVEM or FMOVEM instruction. BASE + OFFSET represents >> ! the lowest memory address. COUNT is the number of registers to be >> ! moved, with register REGNO + I being moved if bit I of MASK is set. >> ! STORE_P specifies the direction of the move and ADJUST_STACK_P says >> ! whether or not this is pre-decrement (if STORE_P) or post-increment >> ! (if !STORE_P) operation. */ >> ! >> ! static rtx >> ! m68k_emit_movem (rtx base, HOST_WIDE_INT offset, >> ! unsigned int count, unsigned int regno, >> ! unsigned int mask, bool store_p, bool adjust_stack_p) >> ! { >> ! int i; >> ! rtx body, addr, src, operands[2]; >> ! enum machine_mode mode; >> ! >> ! body = gen_rtx_PARALLEL (VOIDmode, rtvec_alloc (adjust_stack_p + count)); >> ! mode = reg_raw_mode[regno]; >> ! i = 0; >> ! >> ! if (adjust_stack_p) >> ! { >> ! src = plus_constant (base, (count >> ! * GET_MODE_SIZE (mode) >> ! * (HOST_WIDE_INT) (store_p ? -1 : 1))); >> ! XVECEXP (body, 0, i++) = gen_rtx_SET (VOIDmode, base, src); >> ! } > > Unless something changed recently, this won't work. Although this is a > parallel, the parser for the frame information scans and executes this > serially and all following stack assignments would get a wrong offset. The > parser could be fixed, but the simpler fix is to just put this at the end. I'll double-check this. If it's true, I'll fix the parser. It's daft to work around problems like this. >> ! (define_insn "*m68k_store_multiple_automod" >> ! [(match_parallel 0 "" >> ! [(set (match_operand:SI 1 "register_operand" "=a") >> ! (plus:SI (match_operand:SI 2 "register_operand" "1") >> ! (match_operand:SI 3 "const_int_operand")))])] >> ! "m68k_movem_pattern_p (operands[0], operands[1], INTVAL (operands[3]), true)" >> ! { >> ! return m68k_output_movem (operands, operands[0], INTVAL (operands[3]), true); >> ! }) > > I have a different version of this patch (which unfortunately had a few > pieces missing, so I never submitted it), which does this: > > (define_insn "*moveml_store" > [(match_parallel 0 "movem_operation" > [(unspec:SI [(match_operand:SI 1 "const_int_operand" "i") > (match_operand:BLK 2 "memory_operand" "=m")] UNSPEC_MOVEM) > (set (match_operand:SI 3 "memory_operand" "=g") > (match_operand:SI 4 "register_operand" "r"))])] > "" > "movem%.l %1,%2") > > This means it uses a unspec for instruction parameter and I'm also > considering to move the rest of the pattern into a frame related note, so > the big m68k_movem_pattern_p/m68k_output_movem functions become > unneccessary. I think this is a bad idea. You're exposing the instruction to post-reload optimisers, which are free to make any change they see fit, provided that the new rtl sequence is behaviourally equivalent. They won't know how to update operand 1 after any such changes. I think it's important to check the consistency of the operands, at which point you're not really gaining anything over m68k_movem_pattern_p & m68k_output_movem. My hope was that movem could be used for other things too (inline memcpy()s, maybe), which would mean that even the pre-reload optimisers would get to see these insns. Richard ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 36/63] Use RTL for prologues and epilogues 2007-01-22 20:07 ` Richard Sandiford @ 2007-01-23 1:05 ` Roman Zippel 2007-01-23 7:37 ` Richard Sandiford 2007-01-29 10:23 ` Improve PARALLEL handling in dwarf2out_frame_debug_expr Richard Sandiford 1 sibling, 1 reply; 280+ messages in thread From: Roman Zippel @ 2007-01-23 1:05 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches Hi, On Mon, 22 Jan 2007, Richard Sandiford wrote: > > (define_insn "*moveml_store" > > [(match_parallel 0 "movem_operation" > > [(unspec:SI [(match_operand:SI 1 "const_int_operand" "i") > > (match_operand:BLK 2 "memory_operand" "=m")] UNSPEC_MOVEM) > > (set (match_operand:SI 3 "memory_operand" "=g") > > (match_operand:SI 4 "register_operand" "r"))])] > > "" > > "movem%.l %1,%2") > > > > This means it uses a unspec for instruction parameter and I'm also > > considering to move the rest of the pattern into a frame related note, so > > the big m68k_movem_pattern_p/m68k_output_movem functions become > > unneccessary. > > I think this is a bad idea. You're exposing the instruction to > post-reload optimisers, which are free to make any change they > see fit, provided that the new rtl sequence is behaviourally > equivalent. They won't know how to update operand 1 after > any such changes. I think it's important to check the consistency > of the operands, at which point you're not really gaining anything > over m68k_movem_pattern_p & m68k_output_movem. These operands are inside an unspec, why should they do that? > My hope was that movem could be used for other things too > (inline memcpy()s, maybe), which would mean that even the > pre-reload optimisers would get to see these insns. This is a rather complex pattern, so I doubt it will be very useful, before reload it's better to have simple patterns and I have no idea how you want to get this through register allocation. Patterns like this are used in {load,store}_multiple and AFAICT it's only used for function parameters, where the hard registers are known. What kind of pre-reload optimisations are you thinking of? bye, Roman ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 36/63] Use RTL for prologues and epilogues 2007-01-23 1:05 ` Roman Zippel @ 2007-01-23 7:37 ` Richard Sandiford 2007-01-23 14:20 ` Roman Zippel 0 siblings, 1 reply; 280+ messages in thread From: Richard Sandiford @ 2007-01-23 7:37 UTC (permalink / raw) To: Roman Zippel; +Cc: gcc-patches Roman Zippel <zippel@linux-m68k.org> writes: > On Mon, 22 Jan 2007, Richard Sandiford wrote: > >> > (define_insn "*moveml_store" >> > [(match_parallel 0 "movem_operation" >> > [(unspec:SI [(match_operand:SI 1 "const_int_operand" "i") >> > (match_operand:BLK 2 "memory_operand" "=m")] UNSPEC_MOVEM) >> > (set (match_operand:SI 3 "memory_operand" "=g") >> > (match_operand:SI 4 "register_operand" "r"))])] >> > "" >> > "movem%.l %1,%2") >> > >> > This means it uses a unspec for instruction parameter and I'm also >> > considering to move the rest of the pattern into a frame related note, so >> > the big m68k_movem_pattern_p/m68k_output_movem functions become >> > unneccessary. >> >> I think this is a bad idea. You're exposing the instruction to >> post-reload optimisers, which are free to make any change they >> see fit, provided that the new rtl sequence is behaviourally >> equivalent. They won't know how to update operand 1 after >> any such changes. I think it's important to check the consistency >> of the operands, at which point you're not really gaining anything >> over m68k_movem_pattern_p & m68k_output_movem. > > These operands are inside an unspec, why should they do that? Only operands 1 and 2 are inside an unspec. The actual SET operands are not. My point is that the SET operands could in principle be changed without updating operands 1 or 2. The rtl optimisers are not obliged to consider the possibility that the number of a hard register operand is encoded in some other constant operand. >> My hope was that movem could be used for other things too >> (inline memcpy()s, maybe), which would mean that even the >> pre-reload optimisers would get to see these insns. > > This is a rather complex pattern, so I doubt it will be very useful, > before reload it's better to have simple patterns and I have no idea how > you want to get this through register allocation. > Patterns like this are used in {load,store}_multiple and AFAICT it's only > used for function parameters, where the hard registers are known. > What kind of pre-reload optimisations are you thinking of? In answer to the last point, I was saying that instructions created by things like movstr expanders would be seen by pre-reload optimisers. It was just a general statement; I wasn't thinking of any optimisation in particular. And yes, these patterns are designed to only accept hard registers. The difference is that the patterns in the patch enforce consistency whereas (from what I gather of movem_operation), the pattern above doesn't. Richard ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 36/63] Use RTL for prologues and epilogues 2007-01-23 7:37 ` Richard Sandiford @ 2007-01-23 14:20 ` Roman Zippel 2007-01-23 16:12 ` Richard Sandiford 0 siblings, 1 reply; 280+ messages in thread From: Roman Zippel @ 2007-01-23 14:20 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches Hi, On Tue, 23 Jan 2007, Richard Sandiford wrote: > > These operands are inside an unspec, why should they do that? > > Only operands 1 and 2 are inside an unspec. The actual SET operands > are not. My point is that the SET operands could in principle be > changed without updating operands 1 or 2. The rtl optimisers are > not obliged to consider the possibility that the number of a hard > register operand is encoded in some other constant operand. That's why I said I'm considering to move the set part into a frame related note. > >> My hope was that movem could be used for other things too > >> (inline memcpy()s, maybe), which would mean that even the > >> pre-reload optimisers would get to see these insns. > > > > This is a rather complex pattern, so I doubt it will be very useful, > > before reload it's better to have simple patterns and I have no idea how > > you want to get this through register allocation. > > Patterns like this are used in {load,store}_multiple and AFAICT it's only > > used for function parameters, where the hard registers are known. > > What kind of pre-reload optimisations are you thinking of? > > In answer to the last point, I was saying that instructions created by > things like movstr expanders would be seen by pre-reload optimisers. > It was just a general statement; I wasn't thinking of any optimisation > in particular. > > And yes, these patterns are designed to only accept hard registers. > The difference is that the patterns in the patch enforce consistency > whereas (from what I gather of movem_operation), the pattern above > doesn't. Considering the possibility we generate a movem pattern before reload, the pattern would be readonly anyway and would only have informational value and could be optional. The predicate check would then simply verify that this extra information matches the information in the unspec. OTOH considering that there is currently no use for this detailed information, I'd rather keep it simple (and the unspec doesn't preclude adding this information later). bye, Roman ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 36/63] Use RTL for prologues and epilogues 2007-01-23 14:20 ` Roman Zippel @ 2007-01-23 16:12 ` Richard Sandiford 2007-01-23 16:50 ` Roman Zippel 0 siblings, 1 reply; 280+ messages in thread From: Richard Sandiford @ 2007-01-23 16:12 UTC (permalink / raw) To: Roman Zippel; +Cc: gcc-patches Roman Zippel <zippel@linux-m68k.org> writes: > On Tue, 23 Jan 2007, Richard Sandiford wrote: >> >> My hope was that movem could be used for other things too >> >> (inline memcpy()s, maybe), which would mean that even the >> >> pre-reload optimisers would get to see these insns. >> > >> > This is a rather complex pattern, so I doubt it will be very useful, >> > before reload it's better to have simple patterns and I have no idea how >> > you want to get this through register allocation. >> > Patterns like this are used in {load,store}_multiple and AFAICT it's only >> > used for function parameters, where the hard registers are known. >> > What kind of pre-reload optimisations are you thinking of? >> >> In answer to the last point, I was saying that instructions created by >> things like movstr expanders would be seen by pre-reload optimisers. >> It was just a general statement; I wasn't thinking of any optimisation >> in particular. >> >> And yes, these patterns are designed to only accept hard registers. >> The difference is that the patterns in the patch enforce consistency >> whereas (from what I gather of movem_operation), the pattern above >> doesn't. > > Considering the possibility we generate a movem pattern before reload, the > pattern would be readonly anyway and would only have informational value > and could be optional. The predicate check would then simply verify that > this extra information matches the information in the unspec. > > OTOH considering that there is currently no use for this detailed > information, I'd rather keep it simple (and the unspec doesn't preclude > adding this information later). I simply don't understand this argument. The patch I posted describes what the pattern does in ordinary RTL, and verifies that the pattern is a valid h/w instruction. That seems exactly the right thing to do. Why go out of your way to introduce an unspec when a patch that doesn't need it already exists? I'm not sure this argument is getting us anywhere though. It's not our call, so let's see what the maintainers think. Richard ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 36/63] Use RTL for prologues and epilogues 2007-01-23 16:12 ` Richard Sandiford @ 2007-01-23 16:50 ` Roman Zippel 2007-01-24 19:43 ` Jeffrey Law 0 siblings, 1 reply; 280+ messages in thread From: Roman Zippel @ 2007-01-23 16:50 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches Hi, On Tue, 23 Jan 2007, Richard Sandiford wrote: > > Considering the possibility we generate a movem pattern before reload, the > > pattern would be readonly anyway and would only have informational value > > and could be optional. The predicate check would then simply verify that > > this extra information matches the information in the unspec. > > > > OTOH considering that there is currently no use for this detailed > > information, I'd rather keep it simple (and the unspec doesn't preclude > > adding this information later). > > I simply don't understand this argument. The patch I posted > describes what the pattern does in ordinary RTL, and verifies > that the pattern is a valid h/w instruction. That seems exactly > the right thing to do. Why go out of your way to introduce an > unspec when a patch that doesn't need it already exists? The point is that I think that all the verification/extraction code is wasteful for something we know is static. bye, Roman ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 36/63] Use RTL for prologues and epilogues 2007-01-23 16:50 ` Roman Zippel @ 2007-01-24 19:43 ` Jeffrey Law 2007-01-24 23:04 ` Roman Zippel 0 siblings, 1 reply; 280+ messages in thread From: Jeffrey Law @ 2007-01-24 19:43 UTC (permalink / raw) To: Roman Zippel; +Cc: Richard Sandiford, gcc-patches On Tue, 2007-01-23 at 17:50 +0100, Roman Zippel wrote: > Hi, > > On Tue, 23 Jan 2007, Richard Sandiford wrote: > > > > Considering the possibility we generate a movem pattern before reload, the > > > pattern would be readonly anyway and would only have informational value > > > and could be optional. The predicate check would then simply verify that > > > this extra information matches the information in the unspec. > > > > > > OTOH considering that there is currently no use for this detailed > > > information, I'd rather keep it simple (and the unspec doesn't preclude > > > adding this information later). > > > > I simply don't understand this argument. The patch I posted > > describes what the pattern does in ordinary RTL, and verifies > > that the pattern is a valid h/w instruction. That seems exactly > > the right thing to do. Why go out of your way to introduce an > > unspec when a patch that doesn't need it already exists? > > The point is that I think that all the verification/extraction code is > wasteful for something we know is static. I don't see that it's wasteful -- having the RTL mirror what the h/w instruction does is generally the right thing to do unless there is some significant reason to do otherwise. Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 36/63] Use RTL for prologues and epilogues 2007-01-24 19:43 ` Jeffrey Law @ 2007-01-24 23:04 ` Roman Zippel 2007-01-24 23:26 ` Jeffrey Law 0 siblings, 1 reply; 280+ messages in thread From: Roman Zippel @ 2007-01-24 23:04 UTC (permalink / raw) To: Jeffrey Law; +Cc: Richard Sandiford, gcc-patches Hi, On Wed, 24 Jan 2007, Jeffrey Law wrote: > > The point is that I think that all the verification/extraction code is > > wasteful for something we know is static. > I don't see that it's wasteful -- having the RTL mirror what the h/w > instruction does is generally the right thing to do unless there is > some significant reason to do otherwise. Even if it serves no functional purpose? If we supported a syntax like this (describing it as a vector operation): (set [(reg) ...] (mem)) it might actually be useful because the actual arguments aren't duplicated and generic code is more likely to do something useful with it (e.g. modifying the mem address mode). OTOH breaking it up into the single sets, makes it only more complex and expensive to verify, modify and generate. It gets really interesting if m68k's auto increment is added to it. bye, Roman ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 36/63] Use RTL for prologues and epilogues 2007-01-24 23:04 ` Roman Zippel @ 2007-01-24 23:26 ` Jeffrey Law 0 siblings, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-01-24 23:26 UTC (permalink / raw) To: Roman Zippel; +Cc: Richard Sandiford, gcc-patches On Thu, 2007-01-25 at 00:03 +0100, Roman Zippel wrote: > Even if it serves no functional purpose? Yes. There should be a compelling reason to do otherwise. jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Improve PARALLEL handling in dwarf2out_frame_debug_expr 2007-01-22 20:07 ` Richard Sandiford 2007-01-23 1:05 ` Roman Zippel @ 2007-01-29 10:23 ` Richard Sandiford 1 sibling, 0 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-29 10:23 UTC (permalink / raw) To: Roman Zippel; +Cc: gcc-patches Richard Sandiford <richard@codesourcery.com> writes: > Roman Zippel <zippel@linux-m68k.org> writes: >> On Wed, 10 Jan 2007, Richard Sandiford wrote: >>> ! /* Emit RTL for a MOVEM or FMOVEM instruction. BASE + OFFSET represents >>> ! the lowest memory address. COUNT is the number of registers to be >>> ! moved, with register REGNO + I being moved if bit I of MASK is set. >>> ! STORE_P specifies the direction of the move and ADJUST_STACK_P says >>> ! whether or not this is pre-decrement (if STORE_P) or post-increment >>> ! (if !STORE_P) operation. */ >>> ! >>> ! static rtx >>> ! m68k_emit_movem (rtx base, HOST_WIDE_INT offset, >>> ! unsigned int count, unsigned int regno, >>> ! unsigned int mask, bool store_p, bool adjust_stack_p) >>> ! { >>> ! int i; >>> ! rtx body, addr, src, operands[2]; >>> ! enum machine_mode mode; >>> ! >>> ! body = gen_rtx_PARALLEL (VOIDmode, rtvec_alloc (adjust_stack_p + count)); >>> ! mode = reg_raw_mode[regno]; >>> ! i = 0; >>> ! >>> ! if (adjust_stack_p) >>> ! { >>> ! src = plus_constant (base, (count >>> ! * GET_MODE_SIZE (mode) >>> ! * (HOST_WIDE_INT) (store_p ? -1 : 1))); >>> ! XVECEXP (body, 0, i++) = gen_rtx_SET (VOIDmode, base, src); >>> ! } >> >> Unless something changed recently, this won't work. Although this is a >> parallel, the parser for the frame information scans and executes this >> serially and all following stack assignments would get a wrong offset. The >> parser could be fixed, but the simpler fix is to just put this at the end. > > I'll double-check this. If it's true, I'll fix the parser. > It's daft to work around problems like this. Here's the patch. As the comment in the patch says, it doesn't attempt to implement a fully-general version of PARALLEL, but I think it's enough for most uses, and is better than making each backend treat PARALLEL frame rtxes the same as SEQUENCEs. As the problem only affects 680x0 targets, I'm not in a position to run any execution tests to verify it. However, I compiled g++.dg/eh/register1.C with: -O2 -m68020 -fomit-frame-pointer which uses both "movem ...,-(%sp)" and "fmovem ...,-(%sp)". The "readelf -wl" output looked correct: there were three CFA adjustments (one for the initial stack allocation, one for the movem and one for the fmovem) followed by register saves based on the final CFA. The adjustments were by the correct amount and the saves looked to have the right offset. Tested on m68k-linux-gnu (ColdFire) and bootstrapped & regression-tested on x86_64-linux-gnu. OK to install? Richard gcc/ * dwarf2out.c (dwarf2out_frame_debug_expr): Record the register saves in a PARALLEL before the register assignments. Index: gcc/dwarf2out.c =================================================================== --- gcc/dwarf2out.c 2007-01-25 07:21:36.364929000 -0800 +++ gcc/dwarf2out.c 2007-01-29 02:14:13.405778000 -0800 @@ -1524,13 +1524,31 @@ dwarf2out_frame_debug_expr (rtx expr, co { int par_index; int limit = XVECLEN (expr, 0); + rtx elem; - for (par_index = 0; par_index < limit; par_index++) - if (GET_CODE (XVECEXP (expr, 0, par_index)) == SET - && (RTX_FRAME_RELATED_P (XVECEXP (expr, 0, par_index)) - || par_index == 0)) - dwarf2out_frame_debug_expr (XVECEXP (expr, 0, par_index), label); + /* PARALLELs have strict read-modify-write semantics, so we + ought to evaluate every rvalue before changing any lvalue. + It's cumbersome to do that in general, but there's an + easy approximation that is enough for all current users: + handle register saves before register assignments. */ + if (GET_CODE (expr) == PARALLEL) + for (par_index = 0; par_index < limit; par_index++) + { + elem = XVECEXP (expr, 0, par_index); + if (GET_CODE (elem) == SET + && MEM_P (SET_DEST (elem)) + && (RTX_FRAME_RELATED_P (elem) || par_index == 0)) + dwarf2out_frame_debug_expr (elem, label); + } + for (par_index = 0; par_index < limit; par_index++) + { + elem = XVECEXP (expr, 0, par_index); + if (GET_CODE (elem) == SET + && (!MEM_P (SET_DEST (elem)) || GET_CODE (expr) == SEQUENCE) + && (RTX_FRAME_RELATED_P (elem) || par_index == 0)) + dwarf2out_frame_debug_expr (elem, label); + } return; } ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 35/63] Expose dual %d0/%a0 return value in RTL 2007-01-10 11:46 ` [RTL, ColdFire 35/63] Expose dual %d0/%a0 return value in RTL Richard Sandiford 2007-01-10 11:49 ` [ColdFire 36/63] Use RTL for prologues and epilogues Richard Sandiford @ 2007-01-12 16:09 ` Ian Lance Taylor 1 sibling, 0 replies; 280+ messages in thread From: Ian Lance Taylor @ 2007-01-12 16:09 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches Richard Sandiford <richard@codesourcery.com> writes: > 200x-xx-xx Kazu Hirata <kazu@codesourcery.com> > Richard Sandiford <richard@codesourcery.com> > > * doc/tm.texi (TARGET_FUNCTION_VALUE): Expand documentation of > parallels. > * calls.c (expand_call): If the return value is a PARALLEL, > extract its first member. > * config/m68k/linux.h (FUNCTION_EXTRA_EPILOGUE): Remove. > * config/m68k/m68k.c (m68k_output_function_epilogue): Don't > use FUNCTION_EXTRA_EPILOGUE. > (m68k_function_value): Return a PARALLEL if the return value > is of a pointer type. > * config/m68k/netbsd-elf.h (current_function_returns_pointer) > (FUNCTION_EXTRA_EPILOGUE): Remove. > * config/m68k/m68k.md (D0_REG): New constant. This is OK. Thanks. Ian ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 34/63] Don't emit a nop after noreturn calls 2007-01-10 11:44 ` [ColdFire 34/63] Don't emit a nop after noreturn calls Richard Sandiford 2007-01-10 11:46 ` [RTL, ColdFire 35/63] Expose dual %d0/%a0 return value in RTL Richard Sandiford @ 2007-01-10 17:58 ` Jeffrey Law 1 sibling, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-01-10 17:58 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches On Wed, 2007-01-10 at 11:44 +0000, Richard Sandiford wrote: > m68k_output_function_epilogue has code to output a NOP after a noreturn > call. It's there so that gdb can tell that the call came from the > current function, not the one after it. However, Dan says that gdb > doesn't need such help now, so this patch removes it. > > Richard > > > gcc/ > 200x-xx-xx Kazu Hirata <kazu@codesourcery.com> > > * config/m68k/m68k.c (m68k_output_function_epilogue): Don't > output a NOP for empty epilogues. OK. Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 33/63] Force an epilogue when restoring FPU registers 2007-01-10 11:42 ` [ColdFire 33/63] Force an epilogue when restoring FPU registers Richard Sandiford 2007-01-10 11:44 ` [ColdFire 34/63] Don't emit a nop after noreturn calls Richard Sandiford @ 2007-01-10 17:57 ` Jeffrey Law 1 sibling, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-01-10 17:57 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches On Wed, 2007-01-10 at 11:42 +0000, Richard Sandiford wrote: > m68k_use_return_insn correctly returns false if the function needs > to restore integer registers; in that case we need a normal epilogue. > Hoewver, it was failing to do the same if the function needs to > restore floating-point registers. > > Richard > > > gcc/ > * config/m68k/m68k.c (m68k_use_return_insn): Update comments > before function. Extend register save check to include all > registers, not just integer ones. OK. Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 32/63] Delete USE_RETURN_INSN 2007-01-10 11:41 ` [ColdFire 32/63] Delete USE_RETURN_INSN Richard Sandiford 2007-01-10 11:42 ` [ColdFire 33/63] Force an epilogue when restoring FPU registers Richard Sandiford @ 2007-01-10 17:57 ` Jeffrey Law 1 sibling, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-01-10 17:57 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches On Wed, 2007-01-10 at 11:41 +0000, Richard Sandiford wrote: > This patch gets rid of: > > XXX This macro is m68k-specific and only used in m68k.md. */ > #define USE_RETURN_INSN use_return_insn () > > It seems a bit daft to wrap this one function in a macro, especially > if it creates enough confusion for a "XXX" comment to be needed. > > Richard > > > gcc/ > 200x-xx-xx Kazu Hirata <kazu@codesourcery.com> > > * config/m68k/m68k-protos.h (use_return_insn): Rename to... > (m68k_use_return_insn): ...this. > * config/m68k/m68k.h (USE_RETURN_INSN): Delete. > * config/m68k/m68k.c (use_return_insn): Rename to... > (m68k_use_return_insn): ...this. > * config/m68k/m68k.md (return): Use m68k_use_return_insn instead > of USE_RETURN_INSN. OK. Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 31/63] Fix rounding problems in fpgnulib.c 2007-01-10 11:39 ` [ColdFire 31/63] Fix rounding problems in fpgnulib.c Richard Sandiford 2007-01-10 11:41 ` [ColdFire 32/63] Delete USE_RETURN_INSN Richard Sandiford @ 2007-01-11 17:40 ` Jeffrey Law 1 sibling, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-01-11 17:40 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches On Wed, 2007-01-10 at 11:39 +0000, Richard Sandiford wrote: > This patch fixes two bugs in fpgnulib.c's __truncdfsf2. First, > it was not rounding to nearest even; it was rounding halfway cases > towards infinity instead. Second, it was not detecting overflow > in subnormal numbers (i.e. cases where a DFmode subnormal rounds > to FLT_MIN). > > Richard > > > gcc/ > 200x-xx-xx Nathan Sidwell <nathan@codesourcery.com> > > * config/m68k/fpgnulib.c (__truncdfsf2): Implement round to > nearest even, fix denormal rounding overflow. OK. Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 30/63] Fix rounding for ColdFire FPUs 2007-01-10 11:38 ` [ColdFire 30/63] Fix rounding for ColdFire FPUs Richard Sandiford 2007-01-10 11:39 ` [ColdFire 31/63] Fix rounding problems in fpgnulib.c Richard Sandiford @ 2007-01-11 17:35 ` Jeffrey Law 1 sibling, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-01-11 17:35 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches On Wed, 2007-01-10 at 11:38 +0000, Richard Sandiford wrote: > The ColdFire SFmode addition and subtraction patterns do not round the > result to single precision. This caused a miscompilation of some maths > routines, which in turn led to odd results like rintf(-4.5f) == -4.5f. > > I'll need to step back a bit before describing how I think this mistake > was made. The original 68881 was like the x87 in that most rounding > was controlled by the status register, but the 68040 and ColdFire added > alternative instructions that specify the rounding mode directly. > Thus both the 68040 and ColdFire have the following: > > "fadd.fmt" (rounding controlled by FPSCR), > "fsadd.fmt" (round to single precision) and > "fdadd.fmt" (round to double precision). > > However, gcc handles the rounding differently for the 68040 and > ColdFire. The 680x0 patterns use a rounding attribute (<FP:round>) > which maps to the following print_operand sequences: > > %$ : single-precision rounding ("s" for 68040, "" otherwise) > %& : double-precision rounding ("d" for 68040, "" otherwise) > > Thus the patterns can be shared between <68040 and 68040 architectures > and still get the rounding right on the 68040. ColdFire instead uses > separate patterns for pretty much everything, and uses the <FP:prec> > attribute to specify both the precision _and_ the rouding. > > The bug was that, presumably due to cut-&-paste from the 680x0 patterns, > the ColdFire addition and subtraction patterns were using <FP:round> > rather than <FP:prec> for the rounding mode. They were therefore using > %$ and %&, which both map to empty strings on ColdFire. > > This patch adds all the missing rounding specifications that I could > find. The main question was: should we extend the "%$" and "%&" > handling to ColdFire or hard-code the rounding as "s" and "d"? > I think we should be consistent -- either do the former everywhere, > or do the latter everywhere -- and the latter seemed the less > invasive fix. > > A more ambitious fix would be to combine all the ColdFire and 680x0 > SFmode and DFmode patterns, but not today ;) > > Richard > > > gcc/ > * config/m68k/m68k.md (movsf_cf_hard): Use fsmove instead of > f%$smove and f%$move. > (movdf_cf_hard): Use fdmove for cases 0 and 3 and fmove for case 1. > (extendsfdf2_cf): Use fdmove instead of f%&move. > (truncdfsf2_cf): Use fsmove instead of f%$smove. > (add<mode>3_cf, sub<mode>3_cf): Use <FP:prec> instead of <FP:round>. OK. Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 29/63] Fix a movdf bug 2007-01-10 11:35 ` [ColdFire 29/63] Fix a movdf bug Richard Sandiford 2007-01-10 11:38 ` [ColdFire 30/63] Fix rounding for ColdFire FPUs Richard Sandiford @ 2007-01-10 18:44 ` Jeffrey Law 1 sibling, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-01-10 18:44 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches On Wed, 2007-01-10 at 11:35 +0000, Richard Sandiford wrote: > The r<-r case in movdf_cf_hard moves the individual registers in > a fixed order: > > case 4: > return "move%.l %1,%0;move%.l %R1,%R0"; > > It therefore doesn't handle overlap such as (reg:DF d1) <- (reg:DF d0). > > output_move_double knows how to handle reg<-reg moves properly, and we > already use it for r<-m and m<-r. So the fix is trivial: use it for > r<-r too. > > Richard > > > gcc/ > * config/m68k/m68k.md (movdf_cf_hard): Use output_move_double for > GPR<-GPR moves. OK. Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [middle-end, ColdFire 28/63] Change the canonical NaN representation 2007-01-10 11:34 ` [middle-end, ColdFire 28/63] Change the canonical NaN representation Richard Sandiford 2007-01-10 11:35 ` [ColdFire 29/63] Fix a movdf bug Richard Sandiford @ 2007-01-11 5:32 ` Roger Sayle 1 sibling, 0 replies; 280+ messages in thread From: Roger Sayle @ 2007-01-11 5:32 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches Hi Richard, On Wed, 10 Jan 2007, Richard Sandiford wrote: > gcc/ > * real.h (real_format): Add a canonical_nan_lsbs_set field. > (coldfire_single_format): Declare. > (coldfire_double_format): Likewise. > * real.c (encode_ieee_single): Use canonical_nan_lsbs_set instead > of qnan_msb_set to determine the lower bits of a canonical > NaN significand. > (encode_ieee_double): Likewise. > (encode_ieee_quad): Likewise. > (ieee_single_format): Initialize canonical_nan_lsbs_set. > (mips_single_format): Likewise. > (ieee_double_format): Likewise. > (mips_double_format): Likewise. > (ieee_extended_motorola_format): Likewise. > (ieee_extended_intel_96_format): Likewise. > (ieee_extended_intel_128_format): Likewise. > (ieee_extended_intel_96_round_53_format): Likewise. > (ibm_extended_format): Likewise. > (mips_extended_format): Likewise. > (ieee_quad_format): Likewise. > (mips_quad_format): Likewise. > (vax_f_format): Likewise. > (vax_d_format): Likewise. > (vax_g_format): Likewise. > (i370_single_format): Likewise. > (i370_double_format): Likewise. > (decimal_single_format): Likewise. > (decimal_double_format): Likewise. > (decimal_quad_format): Likewise. > (c4x_single_format): Likewise. > (c4x_extended_format): Likewise. > (real_internal_format): Likewise. > (coldfire_single_format): New real_format. > (coldfire_double_format): Likewise. > * config/pdp11/pdp11.c (pdp11_f_format): Initialize > canonical_nan_lsbs_set. > (pdp11_d_format): Likewise. > * config/m68k/m68k.c (override_options): Override REAL_FORMAT_MODE > if TARGET_COLDFIRE_CPU. This is OK for mainline. Once the rush of the merge dies down, it might be a good idea to add a target-dependent memcmp-based testcase to confirm we're generating the bit patterns we're expecting. However I appreciate you've currently got your hands full co-ordinating an impressive 63-patch merge :-) Roger -- ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 26/63] Rework the call and jump handling 2007-01-10 11:28 ` [ColdFire 26/63] Rework the call and jump handling Richard Sandiford 2007-01-10 11:32 ` [ColdFire 27/63] Addressing mode changes and fixes Richard Sandiford @ 2007-01-11 17:30 ` Jeffrey Law 1 sibling, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-01-11 17:30 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches On Wed, 2007-01-10 at 11:28 +0000, Richard Sandiford wrote: > This patch reworks the call and jump code. There are four main aims: > > - To expose the GOT load in m68k_output_pic_call. This has two benefits: > it allows the load to be CSEd, and it removes the need for this code > in m68k_save_reg: > > if (flag_pic && regno == PIC_OFFSET_TABLE_REGNUM) > { > ... > if (!current_function_is_leaf && TARGET_ID_SHARED_LIBRARY) > return true; > } > > (which a later patch will remove). > > - To allow bra.l and bsr.l to be used for PIC calls on ISA B ColdFire > targets. > > - To fix the sequences generated when long branches are not available. > The current code reads: > > else if (optimize_size || TARGET_ID_SHARED_LIBRARY) > out = "move.l %0@GOT(%%a5), %%a1\n\tjsr (%%a1)"; > else > out = "lea %0-.-8,%%a1\n\tjsr 0(%%pc,%%a1)"; > > but the final case isn't always safe. One of %a0 and %a1 is the > incoming return address pointer and the other is the static chain > register (which register is which depends on the configuration). > > (Actually, this isn't true for *-elf on mainline, but it ought > to be. A later patch deals with this.) > > - To fix the potential problems with the SYMBOL_REF_FLAG handling. > At the moment, the port sets SYMBOL_REF_FLAG if a symbol is used > as a call target, and it will then be accepted as a legitimate PIC > constant. However, the symbol could in principle be used in > non-call situations too, and we don't want it to be accepted as > an absolute address. This is admittedly more of a theoretical concern. > > The code for calls is very similar to the code for jumps -- it's > basically just a bsr/jsr vs. bra/jmp choice -- so it would be nice to > have only one copy of the logic. The patch therefore stores the call > sequences for symbolic addresses in two new global strings -- > m68k_symbolic_call and m68k_symbolic_jump -- and sets them both up in > OVERRIDE_OPTIONS. These variables are null if no symbolic calls are > allowed; the address will then be loaded from the GOT. > > The patch avoids the use of SYMBOL_REF_FLAG by defining a new > 'W' constraint for constant call addresses. > > The patch also removes the only use of the %o operand prefix, which > TARGET_PCREL used to output illegitimate MEMs. It therefore removes the > associated print_operand code too. (I don't think any user asms would > use %o because asms will never see illegitimate MEMs.) > > Richard > > > gcc/ > * config/m68k/m68k-protos.h (m68k_output_pic_call): Delete. > (output_call, m68k_legitimize_call_address): Declare. > * config/m68k/m68k.h (EXTRA_CONSTRAINT): Remove unnecessary > parenthesees. Add support for a 'W' constraint. > (LEGITIMATE_PIC_OPERAND_P): Remove SYMBOL_REF_FLAG handling. > (PRINT_OPERAND_PUNCT_VALID_P): Remove comment about 'o'. > (m68k_symbolic_call, m68k_symbolic_jump): Declare. > * config/m68k/m68k.c (m68k_symbolic_call, m68k_symbolic_jump): New > variables. > (override_options): Initialize them. Do not set flag_no_function_cse > for TARGET_ID_SHARED_LIBRARY. > (m68k_output_pic_call): Delete. > (m68k_legitimize_call_address): New function. > (print_operand): Remove the %o prefix. Handle the %p prefix. > (output_call): New function. > (m68k_output_mi_thunk): Use m68k_symbolic_jump. Always load the > target address from the GOT if symbolic jumps are not allowed. > * config/m68k/m68k.md (call, general_operand): Do not set > SYMBOL_REF_FLAG. Use m68k_legitimize_call_address instead. > Merge separate flag_pic and !flag_pic define_insns into... > (*call, *call_value): ...these new patterns. Match the address > rather than the containing MEM and require it to be a call_operand. > Use output_call to generate the asm template. > * config/m68k/predicates.md (const_call_operand): New predicate. > (call_operand): Likewise. OK. I *like* killing the SYMBOL_REF_FLAG stuff. I wasn't ever very happy with it. The use of SYMBOL_REF_FLAG might have also played a role in the need for special casing PIC operands in cmpsi. Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-01-10 11:23 ` [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro Richard Sandiford 2007-01-10 11:24 ` [ColdFire 25/63] Define MODE_INDEX_REG_CLASS for m68k Richard Sandiford @ 2007-01-10 19:30 ` Jeffrey Law 2007-01-10 21:28 ` Richard Sandiford 2007-01-12 15:45 ` Ian Lance Taylor 2 siblings, 1 reply; 280+ messages in thread From: Jeffrey Law @ 2007-01-10 19:30 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches, mark On Wed, 2007-01-10 at 11:23 +0000, Richard Sandiford wrote: > At the moment, gcc expects there to be a single INDEX_REG_CLASS that > applies to all MEM modes. This is not true when using a ColdFire FPU, > as index registers are not allowed for floating-point modes. The port > tries to hack around this by using "<Q>U" instead of "m" in the movsf > constraints, but that's only a half solution. If reload has to reload > an indexed MEM (rather than the MEM's address), it will expect that > instruction to match. > > The fix is to allow the class of index register to vary depending on > the mode of the addressed value, as the base register class already can. > > This patch does the target-independent bit. It adds new target macros > called MODE_INDEX_REG_CLASS and REGNO_MODE_OK_FOR_INDEX_P, to accompany > the existing MODE_BASE_REG_CLASS and REGNO_MODE_OK_FOR_BASE_P. It also > defines index equivalents of the addresses.h base functions. This is > all a direct image of the base register code (including the wording > of comments and documentation). I think the two should be consistent. > The patch then adjusts all code to use thse new addresses.h functions. > > Bootstrapped & regression-tested on x86_64-linux-gnu. Umm, I'm not sure this is safe, though maybe I'm misunderstanding something. The fundamental problem as I see it is that there are addressing modes which are sometimes valid and sometimes not valid. In this particular case whether or not the addressing mode is valid is a function of whether or not the load/store is an FPU load/store. Your solution is to allow GCC to peek at the mode (of the MEM?) to determine address validity -- but that's not right. The mode of the MEM is not a reliable indicator of whether or not we're using a floating point load/store. ie, it is possible to have an integer mode load/store using FP load/store instructions or an floating point mode load/store using integer load/store instructions. Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-01-10 19:30 ` [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro Jeffrey Law @ 2007-01-10 21:28 ` Richard Sandiford 2007-01-16 21:42 ` Jeffrey Law 0 siblings, 1 reply; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 21:28 UTC (permalink / raw) To: law; +Cc: gcc-patches, mark Jeffrey Law <law@redhat.com> writes: > On Wed, 2007-01-10 at 11:23 +0000, Richard Sandiford wrote: >> At the moment, gcc expects there to be a single INDEX_REG_CLASS that >> applies to all MEM modes. This is not true when using a ColdFire FPU, >> as index registers are not allowed for floating-point modes. The port >> tries to hack around this by using "<Q>U" instead of "m" in the movsf >> constraints, but that's only a half solution. If reload has to reload >> an indexed MEM (rather than the MEM's address), it will expect that >> instruction to match. >> >> The fix is to allow the class of index register to vary depending on >> the mode of the addressed value, as the base register class already can. >> >> This patch does the target-independent bit. It adds new target macros >> called MODE_INDEX_REG_CLASS and REGNO_MODE_OK_FOR_INDEX_P, to accompany >> the existing MODE_BASE_REG_CLASS and REGNO_MODE_OK_FOR_BASE_P. It also >> defines index equivalents of the addresses.h base functions. This is >> all a direct image of the base register code (including the wording >> of comments and documentation). I think the two should be consistent. >> The patch then adjusts all code to use thse new addresses.h functions. >> >> Bootstrapped & regression-tested on x86_64-linux-gnu. > Umm, I'm not sure this is safe, though maybe I'm misunderstanding > something. > > The fundamental problem as I see it is that there are addressing > modes which are sometimes valid and sometimes not valid. In this > particular case whether or not the addressing mode is valid is a > function of whether or not the load/store is an FPU load/store. Right, that describes the ISA restrictions. But this patch isn't really about the ISA restrictions per se. The m68k port makes a pragmatic decision to forbid indexed addressing modes for _all_ SFmode and DFmode MEMs if TARGET_COLDFIRE_FPU, on the basis that the vast majority of memory accesses will be in FPU instructions. We then expose the necessary addressing code to the pre-reload optimisers and register allocators, rather than leaving reload to find scratch address registers from somewhere. Although I didn't make that decision (it's what current mainline does), I can well imagine that it leads to better code. In other words, this is entirely an internal gcc thing. The current definition of INDEX_REG_CLASS tricks reload into thinking that indexed addressing modes are acceptable SFmode and DFmode memory_operands, which they aren't. It will then use such memories in copy-in and copy-out reload instructions. Richard ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-01-10 21:28 ` Richard Sandiford @ 2007-01-16 21:42 ` Jeffrey Law 2007-01-17 5:36 ` Richard Sandiford 0 siblings, 1 reply; 280+ messages in thread From: Jeffrey Law @ 2007-01-16 21:42 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches, mark On Wed, 2007-01-10 at 21:27 +0000, Richard Sandiford wrote: > Right, that describes the ISA restrictions. But this patch isn't > really about the ISA restrictions per se. The m68k port makes a pragmatic > decision to forbid indexed addressing modes for _all_ SFmode and DFmode > MEMs if TARGET_COLDFIRE_FPU, on the basis that the vast majority of > memory accesses will be in FPU instructions. We then expose the > necessary addressing code to the pre-reload optimisers and register > allocators, rather than leaving reload to find scratch address registers > from somewhere. Although I didn't make that decision (it's what current > mainline does), I can well imagine that it leads to better code. > > In other words, this is entirely an internal gcc thing. The current > definition of INDEX_REG_CLASS tricks reload into thinking that indexed > addressing modes are acceptable SFmode and DFmode memory_operands, > which they aren't. It will then use such memories in copy-in and > copy-out reload instructions. The fundamental problem is that the m68k port is lying and you're hacking up reload to deal with the m68k version of the lie. FWIW, the PA port lies too, but all the hair of the lie is buried in the backend. You might review how the PA handles this situation since they are quite similar (basically reversed -- the PA has full indexed addressing modes for loads/stores using FP registers, but not for integer registers. Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-01-16 21:42 ` Jeffrey Law @ 2007-01-17 5:36 ` Richard Sandiford 2007-01-17 6:07 ` Ian Lance Taylor ` (3 more replies) 0 siblings, 4 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-17 5:36 UTC (permalink / raw) To: law; +Cc: gcc-patches, mark Jeffrey Law <law@redhat.com> writes: > On Wed, 2007-01-10 at 21:27 +0000, Richard Sandiford wrote: >> Right, that describes the ISA restrictions. But this patch isn't >> really about the ISA restrictions per se. The m68k port makes a pragmatic >> decision to forbid indexed addressing modes for _all_ SFmode and DFmode >> MEMs if TARGET_COLDFIRE_FPU, on the basis that the vast majority of >> memory accesses will be in FPU instructions. We then expose the >> necessary addressing code to the pre-reload optimisers and register >> allocators, rather than leaving reload to find scratch address registers >> from somewhere. Although I didn't make that decision (it's what current >> mainline does), I can well imagine that it leads to better code. >> >> In other words, this is entirely an internal gcc thing. The current >> definition of INDEX_REG_CLASS tricks reload into thinking that indexed >> addressing modes are acceptable SFmode and DFmode memory_operands, >> which they aren't. It will then use such memories in copy-in and >> copy-out reload instructions. > The fundamental problem is that the m68k port is lying and you're > hacking up reload to deal with the m68k version of the lie. I disagree that this patch is a hack. I think the only real liar here is INDEX_REG_CLASS, which says that something is a valid index register even when GO_IF_LEGITIMATE_ADDRESS forbids it. I think the situation after the patch is self-consistent and the correct approach to take (in terms of what addresses are and aren't acceptable). > FWIW, the PA port lies too, but all the hair of the lie is buried in > the backend. You might review how the PA handles this situation since > they are quite similar (basically reversed -- the PA has full indexed > addressing modes for loads/stores using FP registers, but not for > integer registers. To recap, the original problem was that reload creates copy-in reloads from (or copy-out reloads to) invalid indexed addresses. This can happen when a spill slot MEM has an out-of-range offset, for example. If I've understood correctly, the PA port only avoids this problem for SImode MEMs because it defines LEGITIMIZE_RELOAD_ADDRESS. L_R_A deals with out-of-range offsets by adding the high part of the offset to the base and then adding the left-over offset. I'm sure that this definition was added purely for the sake of optimisation, but it has the side-effect of stopping reload from loading out-of-range offsets into index registers. Would everything still work without L_R_A? If not, that seems a little suspect. I'd always been told that L_R_A should only be used for optimisation, and that it was wrong to rely on it for correctness. The wider issue seems to be: should we either (a) allow indexed addresses for all modes and use constraints and secondary reloads to handle the cases where they aren't allowed or (b) prevent the use of index registers for modes if the vast majority of MEMs in those modes are likely to not be index registers. (a) is what PA does and (b) is what m68k does. I think (b) is the right choice for the reason outlined in the quote above: if we allow indexed MEMs before reload, it's up to reload to convert indexed MEMs into legitimate addresses. To do that it needs some scratch register, which it will pick in an ad-hoc way. It's better to expose the scratch register before reload if possible, and that's what (b) does. Note that the effect is likely to be more obvious on m68k than PA because the m68k port sometimes has only 5 allocatable address registers (after you've taken away the stack pointer, frame pointer and PIC register). Note that the m68k port already deals with SImode indexed MEMs in the same way as the PA. It accepts indexed addresses and use constraints to restrict the choice. Richard ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-01-17 5:36 ` Richard Sandiford @ 2007-01-17 6:07 ` Ian Lance Taylor 2007-01-17 6:30 ` Jeffrey Law 2007-01-18 19:37 ` Richard Sandiford ` (2 subsequent siblings) 3 siblings, 1 reply; 280+ messages in thread From: Ian Lance Taylor @ 2007-01-17 6:07 UTC (permalink / raw) To: Richard Sandiford; +Cc: law, gcc-patches, mark Richard Sandiford <richard@codesourcery.com> writes: > I'd always been told that L_R_A should > only be used for optimisation, and that it was wrong to rely on it for > correctness. I want to comment that I've heard people say that too, but I think it is, well, over optimistic. When weird addressing modes are in play, I believe that LEGITIMIZE_RELOAD_ADDRESS is currently required to handle them. The alternative is to teach reload about all possibilities for all chips, and that does not make sense to me. Ian ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-01-17 6:07 ` Ian Lance Taylor @ 2007-01-17 6:30 ` Jeffrey Law 2007-01-17 13:57 ` Ian Lance Taylor 0 siblings, 1 reply; 280+ messages in thread From: Jeffrey Law @ 2007-01-17 6:30 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: Richard Sandiford, gcc-patches, mark On Tue, 2007-01-16 at 22:07 -0800, Ian Lance Taylor wrote: > Richard Sandiford <richard@codesourcery.com> writes: > > > I'd always been told that L_R_A should > > only be used for optimisation, and that it was wrong to rely on it for > > correctness. > > I want to comment that I've heard people say that too, but I think it > is, well, over optimistic. When weird addressing modes are in play, I > believe that LEGITIMIZE_RELOAD_ADDRESS is currently required to handle > them. The alternative is to teach reload about all possibilities for > all chips, and that does not make sense to me. As the original submitter of L_R_A, I can confirm that the original intent (and it was thoroughly discussed) was for L_R_A to be purely an optimization and any port which requires definition of L_R_A was considered broken. Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-01-17 6:30 ` Jeffrey Law @ 2007-01-17 13:57 ` Ian Lance Taylor 2007-01-17 16:49 ` Jeffrey Law 0 siblings, 1 reply; 280+ messages in thread From: Ian Lance Taylor @ 2007-01-17 13:57 UTC (permalink / raw) To: law; +Cc: Richard Sandiford, gcc-patches, mark Jeffrey Law <law@redhat.com> writes: > On Tue, 2007-01-16 at 22:07 -0800, Ian Lance Taylor wrote: > > Richard Sandiford <richard@codesourcery.com> writes: > > > > > I'd always been told that L_R_A should > > > only be used for optimisation, and that it was wrong to rely on it for > > > correctness. > > > > I want to comment that I've heard people say that too, but I think it > > is, well, over optimistic. When weird addressing modes are in play, I > > believe that LEGITIMIZE_RELOAD_ADDRESS is currently required to handle > > them. The alternative is to teach reload about all possibilities for > > all chips, and that does not make sense to me. > As the original submitter of L_R_A, I can confirm that the original > intent (and it was thoroughly discussed) was for L_R_A to be purely > an optimization and any port which requires definition of L_R_A was > considered broken. I know, but I think that it doesn't actually work that way. There are too many weird addressing modes these days. Ian ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-01-17 13:57 ` Ian Lance Taylor @ 2007-01-17 16:49 ` Jeffrey Law 2007-01-17 16:57 ` Ian Lance Taylor 0 siblings, 1 reply; 280+ messages in thread From: Jeffrey Law @ 2007-01-17 16:49 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: Richard Sandiford, gcc-patches, mark On Wed, 2007-01-17 at 05:56 -0800, Ian Lance Taylor wrote: > Jeffrey Law <law@redhat.com> writes: > > > On Tue, 2007-01-16 at 22:07 -0800, Ian Lance Taylor wrote: > > > Richard Sandiford <richard@codesourcery.com> writes: > > > > > > > I'd always been told that L_R_A should > > > > only be used for optimisation, and that it was wrong to rely on it for > > > > correctness. > > > > > > I want to comment that I've heard people say that too, but I think it > > > is, well, over optimistic. When weird addressing modes are in play, I > > > believe that LEGITIMIZE_RELOAD_ADDRESS is currently required to handle > > > them. The alternative is to teach reload about all possibilities for > > > all chips, and that does not make sense to me. > > As the original submitter of L_R_A, I can confirm that the original > > intent (and it was thoroughly discussed) was for L_R_A to be purely > > an optimization and any port which requires definition of L_R_A was > > considered broken. > > I know, but I think that it doesn't actually work that way. There are > too many weird addressing modes these days. I'm not seeing anything in modern chips that we weren't already dealing with in one way or another when I introduced L_R_A. Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-01-17 16:49 ` Jeffrey Law @ 2007-01-17 16:57 ` Ian Lance Taylor 2007-01-17 17:27 ` Jeffrey Law 0 siblings, 1 reply; 280+ messages in thread From: Ian Lance Taylor @ 2007-01-17 16:57 UTC (permalink / raw) To: law; +Cc: Richard Sandiford, gcc-patches, mark Jeffrey Law <law@redhat.com> writes: > > > As the original submitter of L_R_A, I can confirm that the original > > > intent (and it was thoroughly discussed) was for L_R_A to be purely > > > an optimization and any port which requires definition of L_R_A was > > > considered broken. > > > > I know, but I think that it doesn't actually work that way. There are > > too many weird addressing modes these days. > I'm not seeing anything in modern chips that we weren't already > dealing with in one way or another when I introduced L_R_A. Look at LEGITIMIZE_RELOAD_ADDRESS in avr.h and c4x.h. Anyhow, we do have LEGITIMIZE_RELOAD_ADDRESS today. Would we gain anything by saying that it should never be required? Ian ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-01-17 16:57 ` Ian Lance Taylor @ 2007-01-17 17:27 ` Jeffrey Law 2007-01-17 18:09 ` Richard Sandiford 0 siblings, 1 reply; 280+ messages in thread From: Jeffrey Law @ 2007-01-17 17:27 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: Richard Sandiford, gcc-patches, mark On Wed, 2007-01-17 at 08:57 -0800, Ian Lance Taylor wrote: > Jeffrey Law <law@redhat.com> writes: > > > > > As the original submitter of L_R_A, I can confirm that the original > > > > intent (and it was thoroughly discussed) was for L_R_A to be purely > > > > an optimization and any port which requires definition of L_R_A was > > > > considered broken. > > > > > > I know, but I think that it doesn't actually work that way. There are > > > too many weird addressing modes these days. > > I'm not seeing anything in modern chips that we weren't already > > dealing with in one way or another when I introduced L_R_A. > > Look at LEGITIMIZE_RELOAD_ADDRESS in avr.h and c4x.h. I don't see anything in c4x that looks terribly new/special; the need to use a fixed register for those addressing modes is annoying but I think this problem could be solved without L_R_A. In fact, it looks very similar to the PA which uses a fixed register in all symbolic addresses. Believe it or not the best solution is to _not_ expose that fixed register in any way shape or form if its only use is for generating symbolic addresses. This is something I fixed on the PA over a decade ago (exposing the fixed register early is probably the worst solution as it kills performance). The avr port doesn't have any comments, but it looks like the first clause is the interesting one (the second appears to be optimizing out-of-bounds constants, which is precisely the kind of thing L_R_A was designed to do). It looks like it's unconditionally reloading autoincrement addresses into POINTER_REGS which smells a lot like it's papering over a bad GO_IF_LEGITIMATE_ADDRESS and/or definition of autoincrement address modes. > > Anyhow, we do have LEGITIMIZE_RELOAD_ADDRESS today. Would we gain > anything by saying that it should never be required? Yes. Dealing with odd addressing modes is commonized so that ports don't have to keep reimplementing stuff, often getting it wrong (and yes, I've had the pleasure of fixing several broken L_R_A implementations through the years). In fact, one could argue that dealing with out-of-bounds constants in reg+d addressing modes ought to be commonized, which would eliminate some of the existing backend L_R_A implementations or at least make them smaller/simpler. Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-01-17 17:27 ` Jeffrey Law @ 2007-01-17 18:09 ` Richard Sandiford 2007-01-17 18:26 ` Ian Lance Taylor 0 siblings, 1 reply; 280+ messages in thread From: Richard Sandiford @ 2007-01-17 18:09 UTC (permalink / raw) To: law; +Cc: Ian Lance Taylor, gcc-patches, mark Jeffrey Law <law@redhat.com> writes: > On Wed, 2007-01-17 at 08:57 -0800, Ian Lance Taylor wrote: >> Anyhow, we do have LEGITIMIZE_RELOAD_ADDRESS today. Would we gain >> anything by saying that it should never be required? > Yes. Dealing with odd addressing modes is commonized so that > ports don't have to keep reimplementing stuff, often getting it > wrong (and yes, I've had the pleasure of fixing several broken > L_R_A implementations through the years). In fact, one could > argue that dealing with out-of-bounds constants in reg+d > addressing modes ought to be commonized, which would eliminate > some of the existing backend L_R_A implementations or at least > make them smaller/simpler. Another datapoint (maybe well-known, but I don't think it's been mentioned yet): Thumb is one target that uses the macro for correctness: /* XXX If an HImode FP+large_offset address is converted to an HImode SP+large_offset address, then reload won't know how to fix it. It sees only that SP isn't valid for HImode, and so reloads the SP into an index register, but the resulting address is still invalid because the offset is too big. We fix it here instead by reloading the entire address. */ (I agree that it's a bad thing btw, just pointing it out.) Richard ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-01-17 18:09 ` Richard Sandiford @ 2007-01-17 18:26 ` Ian Lance Taylor 0 siblings, 0 replies; 280+ messages in thread From: Ian Lance Taylor @ 2007-01-17 18:26 UTC (permalink / raw) To: Richard Sandiford; +Cc: law, gcc-patches, mark Richard Sandiford <richard@codesourcery.com> writes: > Jeffrey Law <law@redhat.com> writes: > > On Wed, 2007-01-17 at 08:57 -0800, Ian Lance Taylor wrote: > >> Anyhow, we do have LEGITIMIZE_RELOAD_ADDRESS today. Would we gain > >> anything by saying that it should never be required? > > Yes. Dealing with odd addressing modes is commonized so that > > ports don't have to keep reimplementing stuff, often getting it > > wrong (and yes, I've had the pleasure of fixing several broken > > L_R_A implementations through the years). In fact, one could > > argue that dealing with out-of-bounds constants in reg+d > > addressing modes ought to be commonized, which would eliminate > > some of the existing backend L_R_A implementations or at least > > make them smaller/simpler. > > Another datapoint (maybe well-known, but I don't think it's been > mentioned yet): Thumb is one target that uses the macro for correctness: > > /* XXX If an HImode FP+large_offset address is converted to an HImode > SP+large_offset address, then reload won't know how to fix it. It sees > only that SP isn't valid for HImode, and so reloads the SP into an index > register, but the resulting address is still invalid because the offset > is too big. We fix it here instead by reloading the entire address. */ > > (I agree that it's a bad thing btw, just pointing it out.) Thanks for the example. Jeff, I understand what you are saying. And it does seem to me that LEGITIMIZE_RELOAD_ADDRESS is broken by design. But I really don't think the solution to weird addressing modes is to make reload even more complicated than it already is. A more natural approach would be to provide functions which LEGITIMIZE_RELOAD_ADDRESS could call. But in general gcc does not have a good scheme for handling memory addresses. Hence, reload. Ian ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-01-17 5:36 ` Richard Sandiford 2007-01-17 6:07 ` Ian Lance Taylor @ 2007-01-18 19:37 ` Richard Sandiford 2007-02-09 15:16 ` Richard Sandiford 2007-01-23 1:23 ` Roman Zippel 2007-02-12 23:17 ` Jeffrey Law 3 siblings, 1 reply; 280+ messages in thread From: Richard Sandiford @ 2007-01-18 19:37 UTC (permalink / raw) To: law; +Cc: gcc-patches, mark Jeff, just to confirm... Richard Sandiford <richard@codesourcery.com> writes: > Jeffrey Law <law@redhat.com> writes: >> On Wed, 2007-01-10 at 21:27 +0000, Richard Sandiford wrote: >>> Right, that describes the ISA restrictions. But this patch isn't >>> really about the ISA restrictions per se. The m68k port makes a pragmatic >>> decision to forbid indexed addressing modes for _all_ SFmode and DFmode >>> MEMs if TARGET_COLDFIRE_FPU, on the basis that the vast majority of >>> memory accesses will be in FPU instructions. We then expose the >>> necessary addressing code to the pre-reload optimisers and register >>> allocators, rather than leaving reload to find scratch address registers >>> from somewhere. Although I didn't make that decision (it's what current >>> mainline does), I can well imagine that it leads to better code. >>> >>> In other words, this is entirely an internal gcc thing. The current >>> definition of INDEX_REG_CLASS tricks reload into thinking that indexed >>> addressing modes are acceptable SFmode and DFmode memory_operands, >>> which they aren't. It will then use such memories in copy-in and >>> copy-out reload instructions. >> The fundamental problem is that the m68k port is lying and you're >> hacking up reload to deal with the m68k version of the lie. > > I disagree that this patch is a hack. I think the only real liar here > is INDEX_REG_CLASS, which says that something is a valid index register > even when GO_IF_LEGITIMATE_ADDRESS forbids it. I think the situation > after the patch is self-consistent and the correct approach to take > (in terms of what addresses are and aren't acceptable). > >> FWIW, the PA port lies too, but all the hair of the lie is buried in >> the backend. You might review how the PA handles this situation since >> they are quite similar (basically reversed -- the PA has full indexed >> addressing modes for loads/stores using FP registers, but not for >> integer registers. > > To recap, the original problem was that reload creates copy-in reloads > from (or copy-out reloads to) invalid indexed addresses. This can > happen when a spill slot MEM has an out-of-range offset, for example. > > If I've understood correctly, the PA port only avoids this problem > for SImode MEMs because it defines LEGITIMIZE_RELOAD_ADDRESS. > L_R_A deals with out-of-range offsets by adding the high part of the > offset to the base and then adding the left-over offset. I'm sure that > this definition was added purely for the sake of optimisation, but it has > the side-effect of stopping reload from loading out-of-range offsets into > index registers. Would everything still work without L_R_A? If not, > that seems a little suspect. I'd always been told that L_R_A should > only be used for optimisation, and that it was wrong to rely on it for > correctness. > > The wider issue seems to be: should we either > > (a) allow indexed addresses for all modes and use constraints and > secondary reloads to handle the cases where they aren't allowed or > > (b) prevent the use of index registers for modes if the vast majority > of MEMs in those modes are likely to not be index registers. > > (a) is what PA does and (b) is what m68k does. I think (b) is the > right choice for the reason outlined in the quote above: if we allow > indexed MEMs before reload, it's up to reload to convert indexed MEMs > into legitimate addresses. To do that it needs some scratch register, > which it will pick in an ad-hoc way. It's better to expose the scratch > register before reload if possible, and that's what (b) does. > Note that the effect is likely to be more obvious on m68k than PA > because the m68k port sometimes has only 5 allocatable address registers > (after you've taken away the stack pointer, frame pointer and > PIC register). > > Note that the m68k port already deals with SImode indexed MEMs in the > same way as the PA. It accepts indexed addresses and use constraints > to restrict the choice. ...do you still object to this MODE_INDEX_REG_CLASS patch, or is it OK to go ahead and commit it? (Ian has already approved it -- thanks -- but I wanted to check whether it was still contentious.) Richard ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-01-18 19:37 ` Richard Sandiford @ 2007-02-09 15:16 ` Richard Sandiford 2007-02-12 17:38 ` Jeffrey Law 2007-02-12 23:27 ` Jeffrey Law 0 siblings, 2 replies; 280+ messages in thread From: Richard Sandiford @ 2007-02-09 15:16 UTC (permalink / raw) To: law; +Cc: gcc-patches, mark In another thread, Jeff wrote: Jeff Law <law@redhat.com> writes: > Richard Sandiford <richard@codesourcery.com> writes: >> OK. Just so we're on the same page, what's the blocking issue here? >> I've tried to answer the PA question. > I haven't had a chance to look at your response yet. I've been on the > road some the last couple weeks and my GCC time is very limited these > days. I think I misled you into thinking there was a new message about this. There wasn't. I was actually referring to parts of the thread you'd already responded to. To recap, your objection was that the m68k port should instead handle indexed registers in the same way as the PA port. So, to make things easier for me, let's call the two alternatives the "m68k way" and the "PA way". The ColdFire FPU has no instructions for moving an indexed address into an FP register. This leads to the crucial point: (a) the move patterns have no alternatives that move an indexed address into an FP register. and, also crucial: (b) (a) will be true for both the "m68k way" and the "PA way". The bug is about addresses generated by find_reloads_address. If double_reg_address_ok is true, find_reloads_address will reload an out-of-range offset into an index register. So let's say we have: (reg:SF pseudo) before reload, and this register is constrained to be an FP register. And let's say that PSEUDO is not allocated a hard register, and instead gets spilled to: (mem:SF (plus:SI fp offset)) where OFFSET is out of range. In this sort of case, find_reloads_address will decide to legitimize the address by reloading offset into an index register. find_reloads then reloads the whole MEM into a floating-point register F. Reload is doing nothing wrong here. However: F <- (mem:SF (plus:SI fp index)) is not going to match any move instruction. Like I say, this will be true for the both the PA way and the m68k way, becuase of (b). The PA way is not in itself a way of fixing this problem. Referring back to the thread: Richard Sandiford <richard@codesourcery.com> writes: > Jeff, just to confirm... > Richard Sandiford <richard@codesourcery.com> writes: >> Jeffrey Law <law@redhat.com> writes: >>> On Wed, 2007-01-10 at 21:27 +0000, Richard Sandiford wrote: >>>> Right, that describes the ISA restrictions. But this patch isn't >>>> really about the ISA restrictions per se. The m68k port makes a pragmatic >>>> decision to forbid indexed addressing modes for _all_ SFmode and DFmode >>>> MEMs if TARGET_COLDFIRE_FPU, on the basis that the vast majority of >>>> memory accesses will be in FPU instructions. We then expose the >>>> necessary addressing code to the pre-reload optimisers and register >>>> allocators, rather than leaving reload to find scratch address registers >>>> from somewhere. Although I didn't make that decision (it's what current >>>> mainline does), I can well imagine that it leads to better code. >>>> >>>> In other words, this is entirely an internal gcc thing. The current >>>> definition of INDEX_REG_CLASS tricks reload into thinking that indexed >>>> addressing modes are acceptable SFmode and DFmode memory_operands, >>>> which they aren't. It will then use such memories in copy-in and >>>> copy-out reload instructions. >>> The fundamental problem is that the m68k port is lying and you're >>> hacking up reload to deal with the m68k version of the lie. >> >> I disagree that this patch is a hack. I think the only real liar here >> is INDEX_REG_CLASS, which says that something is a valid index register >> even when GO_IF_LEGITIMATE_ADDRESS forbids it. I think the situation >> after the patch is self-consistent and the correct approach to take >> (in terms of what addresses are and aren't acceptable). >> >>> FWIW, the PA port lies too, but all the hair of the lie is buried in >>> the backend. You might review how the PA handles this situation since >>> they are quite similar (basically reversed -- the PA has full indexed >>> addressing modes for loads/stores using FP registers, but not for >>> integer registers. >> >> To recap, the original problem was that reload creates copy-in reloads >> from (or copy-out reloads to) invalid indexed addresses. This can >> happen when a spill slot MEM has an out-of-range offset, for example. >> >> If I've understood correctly, the PA port only avoids this problem >> for SImode MEMs because it defines LEGITIMIZE_RELOAD_ADDRESS. >> L_R_A deals with out-of-range offsets by adding the high part of the >> offset to the base and then adding the left-over offset. I'm sure that >> this definition was added purely for the sake of optimisation, but it has >> the side-effect of stopping reload from loading out-of-range offsets into >> index registers. Would everything still work without L_R_A? If not, >> that seems a little suspect. I'd always been told that L_R_A should >> only be used for optimisation, and that it was wrong to rely on it for >> correctness. This started a minithread about whether it was OK to rely on L_R_A for correctness. I think you (Jeff) and I are in the "no" camp and Ian's in the "yes" camp. I was wrong about the PA relying on it for correctness though. The m68k problem doesn't happen on the PA because double_reg_address_ok is false on the PA. That's because the PA doesn't allow disp(base,index) QImode addresses whereas m68k does. However, if the PA did allow disp(base,index) QImode addresses, it would be relying on L_R_A for correctness. Thus something like L_R_A would fix the m68k problem. We could intercept all out-of-range FPmode offsets and legitimize them in the same sort of way as the PA, short-circuiting the normal reload code. However, I see this a hack, and wrong in principlem because I don't think L_R_A should be used for correctness like this. In summary, I think this patch is solving a problem that does not occur on the PA, and that the PA approach doesn't solve. I'll quote the rest of the message because I still stand by it. I don't really have anything to add to it though. >> The wider issue seems to be: should we either >> >> (a) allow indexed addresses for all modes and use constraints and >> secondary reloads to handle the cases where they aren't allowed or >> >> (b) prevent the use of index registers for modes if the vast majority >> of MEMs in those modes are likely to not be index registers. >> >> (a) is what PA does and (b) is what m68k does. I think (b) is the >> right choice for the reason outlined in the quote above: if we allow >> indexed MEMs before reload, it's up to reload to convert indexed MEMs >> into legitimate addresses. To do that it needs some scratch register, >> which it will pick in an ad-hoc way. It's better to expose the scratch >> register before reload if possible, and that's what (b) does. >> Note that the effect is likely to be more obvious on m68k than PA >> because the m68k port sometimes has only 5 allocatable address registers >> (after you've taken away the stack pointer, frame pointer and >> PIC register). >> >> Note that the m68k port already deals with SImode indexed MEMs in the >> same way as the PA. It accepts indexed addresses and use constraints >> to restrict the choice. Richard ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-02-09 15:16 ` Richard Sandiford @ 2007-02-12 17:38 ` Jeffrey Law 2007-02-12 23:09 ` Mark Mitchell 2007-02-12 23:27 ` Jeffrey Law 1 sibling, 1 reply; 280+ messages in thread From: Jeffrey Law @ 2007-02-12 17:38 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches, mark On Fri, 2007-02-09 at 15:13 +0000, Richard Sandiford wrote: > In another thread, Jeff wrote: > > Jeff Law <law@redhat.com> writes: > > Richard Sandiford <richard@codesourcery.com> writes: > >> OK. Just so we're on the same page, what's the blocking issue here? > >> I've tried to answer the PA question. > > I haven't had a chance to look at your response yet. I've been on the > > road some the last couple weeks and my GCC time is very limited these > > days. > > I think I misled you into thinking there was a new message about this. > There wasn't. I was actually referring to parts of the thread you'd > already responded to. You had a followup message that I still haven't read closely. THe issue at hand is I think you're solving this problem in a totally inappropriate way. I need to look at it deeper and see if I can convince myself otherwise. jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-02-12 17:38 ` Jeffrey Law @ 2007-02-12 23:09 ` Mark Mitchell 0 siblings, 0 replies; 280+ messages in thread From: Mark Mitchell @ 2007-02-12 23:09 UTC (permalink / raw) To: law; +Cc: Richard Sandiford, gcc-patches Jeffrey Law wrote: >>>> OK. Just so we're on the same page, what's the blocking issue here? > THe issue at hand is I think you're solving this problem in a totally > inappropriate way. I need to look at it deeper and see if I can > convince myself otherwise. FWIW, I read back through this thread. This isn't an area of the compiler where I'm an expert, so I had to swim around a bit, and I didn't understand everything. But, it sounds like Richard's approach is to prevent the compiler from using certain index registers to access memory in certain modes up front because that avoids cases that are difficult and may result in inferior code. In contrast, it sounds like Jeff is suggesting allowing everything, and then doing something in the back end to fix up problematic accesses that aren't actually supported on the hardware. It seems to me like both approaches are reasonable, and that different back ends might well reasonably take different approaches. If the fix-ups are hard enough, and frequent enough, allowing the compiler the full generality up front seems like it could well be harmful. Given that Richard's patch is a direct parallel to the BASE_REG_CLASS case, it seems a reasonable way to give back ends the ability to say that index registers shouldn't be used to access particular kinds of memory, because that's not likely to be a very optimal way to do it. But, I'm not claiming any kind of particular expertise here. So, this is just my two cents, not anything particularly insightful. -- Mark Mitchell CodeSourcery mark@codesourcery.com (650) 331-3385 x713 ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-02-09 15:16 ` Richard Sandiford 2007-02-12 17:38 ` Jeffrey Law @ 2007-02-12 23:27 ` Jeffrey Law 2007-02-13 18:01 ` Roman Zippel 1 sibling, 1 reply; 280+ messages in thread From: Jeffrey Law @ 2007-02-12 23:27 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches, mark On Fri, 2007-02-09 at 15:13 +0000, Richard Sandiford wrote: > The ColdFire FPU has no instructions for moving an indexed address into > an FP register. This leads to the crucial point: Right. As I've said, this is a subst of the PA (actually, the PA has no way to do an indexed store from an integer register, but that's close enough). > > The bug is about addresses generated by find_reloads_address. If > double_reg_address_ok is true, find_reloads_address will reload an > out-of-range offset into an index register. So let's say we have: And I believe this is the source of your problem. The backend has lied to reload. double_reg_address_ok is computed by generating some RTL for addresses, then passing them along to G_I_L_A. If G_I_L_A returns true, then reload deems it is free to generate reg+reg addressing modes. Specifically the code actually generates (plus (plus (FP) (indexreg)) (const_int 4)) If it's a valid address for any indexreg, then double_reg_address_ok is set to 1 and reload generates reg+reg addressing modes. Stop lying to reload about the legitimacy of that kind of address and these problems ought to go away. You might even look into the idea of rejecting such addresses only for the sake of reload since I think rejecting them in general is likely to lead to a performance issue on the m68k. jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-02-12 23:27 ` Jeffrey Law @ 2007-02-13 18:01 ` Roman Zippel 2007-02-14 10:03 ` Richard Sandiford 0 siblings, 1 reply; 280+ messages in thread From: Roman Zippel @ 2007-02-13 18:01 UTC (permalink / raw) To: Jeffrey Law; +Cc: Richard Sandiford, gcc-patches, mark Hi, On Mon, 12 Feb 2007, Jeffrey Law wrote: > And I believe this is the source of your problem. The backend has > lied to reload. > > double_reg_address_ok is computed by generating some RTL for > addresses, then passing them along to G_I_L_A. If G_I_L_A > returns true, then reload deems it is free to generate reg+reg > addressing modes. I disagree, I believe it's reload that lies to the back end. To be specfific reload asks whether (mem:qi (plus (reg %fp) (reg))) is valid, which the back end answers truthfully and reload then assumes this is valid for any mode. If the latter were true, the mode argument of G_I_L_A would be entirely useless. bye, Roman ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-02-13 18:01 ` Roman Zippel @ 2007-02-14 10:03 ` Richard Sandiford 0 siblings, 0 replies; 280+ messages in thread From: Richard Sandiford @ 2007-02-14 10:03 UTC (permalink / raw) To: Roman Zippel; +Cc: Jeffrey Law, gcc-patches, mark Roman Zippel <zippel@linux-m68k.org> writes: > On Mon, 12 Feb 2007, Jeffrey Law wrote: >> And I believe this is the source of your problem. The backend has >> lied to reload. >> >> double_reg_address_ok is computed by generating some RTL for >> addresses, then passing them along to G_I_L_A. If G_I_L_A >> returns true, then reload deems it is free to generate reg+reg >> addressing modes. > > I disagree, I believe it's reload that lies to the back end. To be > specfific reload asks whether (mem:qi (plus (reg %fp) (reg))) is valid, > which the back end answers truthfully and reload then assumes this is > valid for any mode. If the latter were true, the mode argument of G_I_L_A > would be entirely useless. Exactly! Richard ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-01-17 5:36 ` Richard Sandiford 2007-01-17 6:07 ` Ian Lance Taylor 2007-01-18 19:37 ` Richard Sandiford @ 2007-01-23 1:23 ` Roman Zippel 2007-01-23 8:03 ` Richard Sandiford 2007-02-12 23:17 ` Jeffrey Law 3 siblings, 1 reply; 280+ messages in thread From: Roman Zippel @ 2007-01-23 1:23 UTC (permalink / raw) To: Richard Sandiford; +Cc: law, gcc-patches, mark Hi, On Wed, 17 Jan 2007, Richard Sandiford wrote: > The wider issue seems to be: should we either > > (a) allow indexed addresses for all modes and use constraints and > secondary reloads to handle the cases where they aren't allowed or > > (b) prevent the use of index registers for modes if the vast majority > of MEMs in those modes are likely to not be index registers. > > (a) is what PA does and (b) is what m68k does. I think (b) is the > right choice for the reason outlined in the quote above: if we allow > indexed MEMs before reload, it's up to reload to convert indexed MEMs > into legitimate addresses. To do that it needs some scratch register, > which it will pick in an ad-hoc way. Restricting the addressing modes for fp arguments is reasonable, but I think reload is the wrong place to solve this, by using special fp predicates you can prevent index register reaching reload in first place and make the job of reload easier. bye, Roman ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-01-23 1:23 ` Roman Zippel @ 2007-01-23 8:03 ` Richard Sandiford 2007-01-23 16:47 ` Roman Zippel 0 siblings, 1 reply; 280+ messages in thread From: Richard Sandiford @ 2007-01-23 8:03 UTC (permalink / raw) To: Roman Zippel; +Cc: law, gcc-patches, mark Roman Zippel <zippel@linux-m68k.org> writes: > On Wed, 17 Jan 2007, Richard Sandiford wrote: >> The wider issue seems to be: should we either >> >> (a) allow indexed addresses for all modes and use constraints and >> secondary reloads to handle the cases where they aren't allowed or >> >> (b) prevent the use of index registers for modes if the vast majority >> of MEMs in those modes are likely to not be index registers. >> >> (a) is what PA does and (b) is what m68k does. I think (b) is the >> right choice for the reason outlined in the quote above: if we allow >> indexed MEMs before reload, it's up to reload to convert indexed MEMs >> into legitimate addresses. To do that it needs some scratch register, >> which it will pick in an ad-hoc way. > > Restricting the addressing modes for fp arguments is reasonable, but I > think reload is the wrong place to solve this, by using special fp > predicates you can prevent index register reaching reload in first place > and make the job of reload easier. I don't understand. Indexed SFmode addresses don't exist before reload at the moment either; that's the whole point of (b). And predicates have nothing to do with the problem that this patch is trying to solve. The problem that this patch is trying to solve is that reload itself creates an indexed address, because INDEX_REG_CLASS leads it to believe that such a thing is valid. It does this when the address of a pseudo spill slot has an out-of-range offset. Richard ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-01-23 8:03 ` Richard Sandiford @ 2007-01-23 16:47 ` Roman Zippel 0 siblings, 0 replies; 280+ messages in thread From: Roman Zippel @ 2007-01-23 16:47 UTC (permalink / raw) To: Richard Sandiford; +Cc: law, gcc-patches, mark Hi, On Tue, 23 Jan 2007, Richard Sandiford wrote: > The problem that this patch is trying to solve is that reload itself > creates an indexed address, because INDEX_REG_CLASS leads it to believe > that such a thing is valid. It does this when the address of a pseudo > spill slot has an out-of-range offset. Sorry, I misunderstood, I was a bit confused by the index register stuff, now I know where your patch starts. :) So the basic problem is that double_reg_address_ok doesn't consider the mode/instr. I'm sympathetic to Jeffrey's argument, but in consequence this means address reload happens too early as we don't know yet all constraints. What would be needed is the possibility to delay a single address reload (e.g. via address_reloaded[i]) and once the constraints are known generate the reload based on it (instead of double_reg_address_ok). bye, Roman ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-01-17 5:36 ` Richard Sandiford ` (2 preceding siblings ...) 2007-01-23 1:23 ` Roman Zippel @ 2007-02-12 23:17 ` Jeffrey Law 2007-02-14 10:02 ` Richard Sandiford 3 siblings, 1 reply; 280+ messages in thread From: Jeffrey Law @ 2007-02-12 23:17 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches, mark On Wed, 2007-01-17 at 05:36 +0000, Richard Sandiford wrote: > I disagree that this patch is a hack. I think the only real liar here > is INDEX_REG_CLASS, which says that something is a valid index register > even when GO_IF_LEGITIMATE_ADDRESS forbids it. But note this is precisely the same situation as we have with the PA and IMHO "fixing" it in reload is wrong. The fact that the address is invalid has absolutely nothing to do with INDEX_REG_CLASS and everything to do with whether or not we're using FP load/stores. The PA port's LEGITIMIZE_RELOAD_ADDRESS is only used to optimize the generated reloads, removing LEGITIMIZE_RELOAD_ADDRESS from the PA port will merely generate less optimized code. Reload will grab a scratch register and reload the out of range address into the scratch and go on its merry way. The limited displacement in reg+d addressing on PA1.0 and PA1.1 chips exercised this code extensively before the introduction of L_R_A (IIRC, the PA was the first port to define L_R_A to deal with the horrid code we got because of the limited displacements available on FP loads and stores). > I think the situation > after the patch is self-consistent and the correct approach to take > (in terms of what addresses are and aren't acceptable). Umm, I still disagree. > The wider issue seems to be: should we either > > (a) allow indexed addresses for all modes and use constraints and > secondary reloads to handle the cases where they aren't allowed or > > (b) prevent the use of index registers for modes if the vast majority > of MEMs in those modes are likely to not be index registers. Fundamentally the PA and m68k really need to be rejecting indexed address modes since those modes are not valid addressing modes according to a strict definition of G_I_L_A. The two ports lie about the legitimitacy of such address modes and if they continue to do so, then the details of dealing with the lie really belong in the backend (until such time as someone fixes reload and G_I_L_A to be general enough to handle the kinds of cases that come up on the m68k and PA). Note that the PA doesn't necessarily use constraints to accept or reject indexed addressing modes. IIRC the indexed addressing modes are separate patterns. I don't recall offhand why I made that change, but it could have well been to avoid the kinds of problems you're running into. Basically I still think you're approaching this from the wrong direction. Either hide this in the backend, or if you want to fix reload, then introduce whatever capabilities you need to reload so that G_I_L_A can recognize when the addresses really are or are not valid. For the m68k I think you'd need to introduce the idea of how the address is going to be used. ie, for a load from memory, what kind of register is the target and for a store to memory, what kind of register is the source (note this is different from the mode of the operand, which is purely a GCC-ism and not sufficient). That's a nontrivial problem ;-) I looked at it about 10 years ago. Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-02-12 23:17 ` Jeffrey Law @ 2007-02-14 10:02 ` Richard Sandiford 2007-02-14 17:14 ` Jeffrey Law 0 siblings, 1 reply; 280+ messages in thread From: Richard Sandiford @ 2007-02-14 10:02 UTC (permalink / raw) To: law; +Cc: gcc-patches, mark Jeffrey Law <law@redhat.com> writes: > On Wed, 2007-01-17 at 05:36 +0000, Richard Sandiford wrote: >> The wider issue seems to be: should we either >> >> (a) allow indexed addresses for all modes and use constraints and >> secondary reloads to handle the cases where they aren't allowed or >> >> (b) prevent the use of index registers for modes if the vast majority >> of MEMs in those modes are likely to not be index registers. > Fundamentally the PA and m68k really need to be rejecting indexed > address modes since those modes are not valid addressing modes > according to a strict definition of G_I_L_A. The two ports lie > about the legitimitacy of such address modes and if they continue > to do so, then the details of dealing with the lie really belong > in the backend (until such time as someone fixes reload and > G_I_L_A to be general enough to handle the kinds of cases that > come up on the m68k and PA). I don't agree. You seem to be saying that G_I_L_A has to be independent of the addressed machine_mode, so that if we forbid index registers for SFmode, we must do it for all modes. Or, conversely, if we allow disp(base,index) addresses for QImode, we must do so for SFmode too. As I've said before, I think ColdFire's G_I_L_A should continue rejecting indexed addressing modes for SFmode _not_ for correctness, but for _optimisation_. We want to optimise SFmode code based on the assumption that we will be using the FPU to implement it. We therefore want to expose the lack of indexed addresses early on, so that the pre-reload optimisers and register allocators can see the separate address calculations. Sure, we lose the ability to copy SFmode values around using GPRs and indexed addresses, but the trade-off is IMO a good one. So, _from an optimisation perspective_, I think it is reasonable to accept indexed addresses for SImode and not for SFmode. I'm still not sure whether you disagree with that. Now G_I_L_A has a mode argument _precisely_ so that the legitimacy of an address can depend on the mode. However, G_I_L_A is not the only backend interface for describing addressing modes; we also have the BASE_REG_CLASS and INDEX_REG_CLASS macros. These latter macros are all that reload looks at when legitimizing addresses, so they must of course agree with G_I_L_A. The problem we have at the moment is that, while G_I_L_A and BASE_REG_CLASS are parameterised on the mode (and other things), INDEX_REG_CLASS isn't. So at the moment, it isn't possible for the *_REG_CLASS macros to fully agree with G_I_L_A. My patch is fixing that, and nothing else. You seem to be approaching this from the attitude that I'm trying to solve the question of "how do we expose the different FPR vs. GPR addressing mode restrictions". That's not what I'm trying to solve in this patch. As I see it, the m68k port implements a good optimisation decision, but only does so on one side of its addressing mode code. I'm simply trying to get the other side to agree. The change is simple, and is IMO better than ripping out the optimisation. And I honestly believe this patch is a clean-up as far as the middle-end goes, because we're now using the same interfaces both base and index registers. Richard ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-02-14 10:02 ` Richard Sandiford @ 2007-02-14 17:14 ` Jeffrey Law 2007-02-14 17:31 ` Ian Lance Taylor ` (2 more replies) 0 siblings, 3 replies; 280+ messages in thread From: Jeffrey Law @ 2007-02-14 17:14 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches, mark On Wed, 2007-02-14 at 09:37 +0000, Richard Sandiford wrote: > Jeffrey Law <law@redhat.com> writes: > > On Wed, 2007-01-17 at 05:36 +0000, Richard Sandiford wrote: > >> The wider issue seems to be: should we either > >> > >> (a) allow indexed addresses for all modes and use constraints and > >> secondary reloads to handle the cases where they aren't allowed or > >> > >> (b) prevent the use of index registers for modes if the vast majority > >> of MEMs in those modes are likely to not be index registers. > > Fundamentally the PA and m68k really need to be rejecting indexed > > address modes since those modes are not valid addressing modes > > according to a strict definition of G_I_L_A. The two ports lie > > about the legitimitacy of such address modes and if they continue > > to do so, then the details of dealing with the lie really belong > > in the backend (until such time as someone fixes reload and > > G_I_L_A to be general enough to handle the kinds of cases that > > come up on the m68k and PA). > > I don't agree. You seem to be saying that G_I_L_A has to be independent > of the addressed machine_mode, so that if we forbid index registers for > SFmode, we must do it for all modes. Or, conversely, if we allow > disp(base,index) addresses for QImode, we must do so for SFmode too. Somewhat. It's legitimate to select based on mode, but you must not confuse GCC's concept of a mode with the register file used on the actual hardware. You also have to be careful because of how double_reg_address_ok is computed. double_reg_address_ok blindly uses QImode and if we ever get a valid address in QImode, then reload assumes that it can use indexing for any mode. An alternate (and possibly better) approach to fixing this mess would be to make double_reg_address_ok an array of booleans indexed by mode, then reload could check for validity of double_reg_address_ok for the desired mode rather than assuming that if it's valid for QImode, then it must be valid for other modes. > > As I've said before, I think ColdFire's G_I_L_A should continue > rejecting indexed addressing modes for SFmode _not_ for correctness, > but for _optimisation_. We want to optimise SFmode code based > on the assumption that we will be using the FPU to implement it. > We therefore want to expose the lack of indexed addresses early on, > so that the pre-reload optimisers and register allocators can see the > separate address calculations. Sure, we lose the ability to copy > SFmode values around using GPRs and indexed addresses, but the > trade-off is IMO a good one. I've got absolutely no problems with rejecting addressing modes in G_I_L_A. > So, _from an optimisation perspective_, I think it is reasonable to > accept indexed addresses for SImode and not for SFmode. I'm still > not sure whether you disagree with that. I disagree with that if the port allows integer values in FP regsters and the hardware can't do FP indexed loads/stores because G_I_L_A could be passed SImode but generate an FP load/store. > > Now G_I_L_A has a mode argument _precisely_ so that the legitimacy of > an address can depend on the mode. However, G_I_L_A is not the only > backend interface for describing addressing modes; we also have the > BASE_REG_CLASS and INDEX_REG_CLASS macros. These latter macros are > all that reload looks at when legitimizing addresses, so they must > of course agree with G_I_L_A. I disagree on this point and as I've stated before I think you're using this to avoid fixing the backend to deal with a broken G_I_L_A. > > The problem we have at the moment is that, while G_I_L_A and > BASE_REG_CLASS are parameterised on the mode (and other things), > INDEX_REG_CLASS isn't. So at the moment, it isn't possible for > the *_REG_CLASS macros to fully agree with G_I_L_A. My patch > is fixing that, and nothing else. When did BASE_REG_CLASS get parameterized on the mode? That seems awful wrong as well. I still don't see any valid need for {BASE,INDEX}_REG_CLASS to be parameterized on the mode of the memory reference. Can you point me to the discusion for the BASE_REG_CLASS change? [ God I hope I didn't approve that patch :-) ] Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-02-14 17:14 ` Jeffrey Law @ 2007-02-14 17:31 ` Ian Lance Taylor 2007-02-14 17:37 ` Richard Sandiford 2007-02-14 19:10 ` Roman Zippel 2 siblings, 0 replies; 280+ messages in thread From: Ian Lance Taylor @ 2007-02-14 17:31 UTC (permalink / raw) To: law; +Cc: Richard Sandiford, gcc-patches, mark Jeffrey Law <law@redhat.com> writes: > Can you point me to the discusion for the BASE_REG_CLASS change? For MODE_BASE_REG_CLASS, approved by Bernd: http://gcc.gnu.org/ml/gcc-patches/2001-12/msg01556.html For MODE_BASE_REG_REG_CLASS; I don't know who approved this (it wasn't me--I wasn't a middle-end maintainer at the time): http://gcc.gnu.org/ml/gcc-patches/2004-09/msg01922.html Ian ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-02-14 17:14 ` Jeffrey Law 2007-02-14 17:31 ` Ian Lance Taylor @ 2007-02-14 17:37 ` Richard Sandiford 2007-02-14 17:48 ` Ian Lance Taylor 2007-02-27 20:25 ` Jeffrey Law 2007-02-14 19:10 ` Roman Zippel 2 siblings, 2 replies; 280+ messages in thread From: Richard Sandiford @ 2007-02-14 17:37 UTC (permalink / raw) To: law; +Cc: gcc-patches, mark Jeffrey Law <law@redhat.com> writes: > On Wed, 2007-02-14 at 09:37 +0000, Richard Sandiford wrote: >> I don't agree. You seem to be saying that G_I_L_A has to be independent >> of the addressed machine_mode, so that if we forbid index registers for >> SFmode, we must do it for all modes. Or, conversely, if we allow >> disp(base,index) addresses for QImode, we must do so for SFmode too. > Somewhat. It's legitimate to select based on mode, but you must not > confuse GCC's concept of a mode with the register file used on the > actual hardware. > > You also have to be careful because of how double_reg_address_ok > is computed. double_reg_address_ok blindly uses QImode and if > we ever get a valid address in QImode, then reload assumes that it > can use indexing for any mode. > > An alternate (and possibly better) approach to fixing this mess > would be to make double_reg_address_ok an array of booleans > indexed by mode, then reload could check for validity of > double_reg_address_ok for the desired mode rather than assuming > that if it's valid for QImode, then it must be valid for other > modes. Well, I agree making double_reg_address_ok an array of booleans make sense in principle. However, I think we first need to make INDEX_REG_CLASS and BASE_REG_CLASS agree with G_I_L_A. (INDEX_REG_CLASS is supposed to be NO_REGS if indexing isn't supported.) Once you do that, there is no current need to make double_reg_address_ok an array of booleans, and doing so would just make the compiler slightly slower. So although I agree we should it if some other port needs it (i.e. if some other port allows disp(base,index) addresses for some modes and allows only plain (base,index) address for others), I don't think we should otherwise. It sounds like there's disagreement about whether "making INDEX_REG_CLASS and BASE_REG_CLASS agree with G_I_L_A" is a sensible description though; see [*]. >> So, _from an optimisation perspective_, I think it is reasonable to >> accept indexed addresses for SImode and not for SFmode. I'm still >> not sure whether you disagree with that. > I disagree with that if the port allows integer values in FP regsters > and the hardware can't do FP indexed loads/stores because G_I_L_A > could be passed SImode but generate an FP load/store. But why, again from an optimisation perspective? The majority of SImode operations will be non-FPU operations, and we want to optimise on that basis. The majority of SFmode operations will be FPU operations, and we want to optimise on that basis too. >> Now G_I_L_A has a mode argument _precisely_ so that the legitimacy of >> an address can depend on the mode. However, G_I_L_A is not the only >> backend interface for describing addressing modes; we also have the >> BASE_REG_CLASS and INDEX_REG_CLASS macros. These latter macros are >> all that reload looks at when legitimizing addresses, so they must >> of course agree with G_I_L_A. > I disagree on this point and as I've stated before I think you're > using this to avoid fixing the backend to deal with a broken G_I_L_A. [*] Which part do you disagree with? The last sentence? I was referring specifically to find_reloads_address, with uses these macros to decide how to convert a non-strict memory address into a strict memory address. The result of applying the reloads pushed by find_reloads_address must be a strict memory address. >> The problem we have at the moment is that, while G_I_L_A and >> BASE_REG_CLASS are parameterised on the mode (and other things), >> INDEX_REG_CLASS isn't. So at the moment, it isn't possible for >> the *_REG_CLASS macros to fully agree with G_I_L_A. My patch >> is fixing that, and nothing else. > When did BASE_REG_CLASS get parameterized on the mode? That seems > awful wrong as well. I still don't see any valid need for > {BASE,INDEX}_REG_CLASS to be parameterized on the mode of the > memory reference. > > Can you point me to the discusion for the BASE_REG_CLASS change? > [ God I hope I didn't approve that patch :-) ] Well, these days, BASE_REG_CLASS is parameterised on more than just the mode ;) We have: @defmac BASE_REG_CLASS @defmac MODE_BASE_REG_CLASS (@var{mode}) @defmac MODE_BASE_REG_REG_CLASS (@var{mode}) @defmac MODE_CODE_BASE_REG_CLASS (@var{mode}, @var{outer_code}, @var{index_code}) The original MODE_BASE_REG_CLASS was motivated by thumb: http://gcc.gnu.org/ml/gcc-patches/2001-12/msg01556.html and don't worry, you're in the clear as far as approving it goes. ;) Richard ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-02-14 17:37 ` Richard Sandiford @ 2007-02-14 17:48 ` Ian Lance Taylor 2007-02-15 12:48 ` Bernd Schmidt 2007-02-27 20:22 ` Jeffrey Law 2007-02-27 20:25 ` Jeffrey Law 1 sibling, 2 replies; 280+ messages in thread From: Ian Lance Taylor @ 2007-02-14 17:48 UTC (permalink / raw) To: Richard Sandiford; +Cc: law, gcc-patches, mark Richard Sandiford <richard@codesourcery.com> writes: > @defmac MODE_CODE_BASE_REG_CLASS (@var{mode}, @var{outer_code}, @var{index_code}) Oh yeah, MODE_CODE_BASE_REG_CLASS came in here, written and committed by Bernd: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01952.html Ian ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-02-14 17:48 ` Ian Lance Taylor @ 2007-02-15 12:48 ` Bernd Schmidt 2007-02-23 9:58 ` Mark Mitchell 2007-02-27 20:22 ` Jeffrey Law 1 sibling, 1 reply; 280+ messages in thread From: Bernd Schmidt @ 2007-02-15 12:48 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: Richard Sandiford, law, gcc-patches, mark Ian Lance Taylor wrote: > Richard Sandiford <richard@codesourcery.com> writes: > >> @defmac MODE_CODE_BASE_REG_CLASS (@var{mode}, @var{outer_code}, @var{index_code}) > > Oh yeah, MODE_CODE_BASE_REG_CLASS came in here, written and committed > by Bernd: > http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01952.html FWIW, I think that MODE_INDEX_REG_CLASS is a straightforward generalization of what we have now, but I don't want to approve the patch over Jeff's head while he has concerns. Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, Vincent Roche, Joseph E. McDonough ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-02-15 12:48 ` Bernd Schmidt @ 2007-02-23 9:58 ` Mark Mitchell 2007-02-27 0:30 ` Jeffrey Law 0 siblings, 1 reply; 280+ messages in thread From: Mark Mitchell @ 2007-02-23 9:58 UTC (permalink / raw) To: Bernd Schmidt; +Cc: Ian Lance Taylor, Richard Sandiford, law, gcc-patches Bernd Schmidt wrote: > Ian Lance Taylor wrote: >> Richard Sandiford <richard@codesourcery.com> writes: >> >>> @defmac MODE_CODE_BASE_REG_CLASS (@var{mode}, @var{outer_code}, >>> @var{index_code}) >> >> Oh yeah, MODE_CODE_BASE_REG_CLASS came in here, written and committed >> by Bernd: >> http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01952.html > > FWIW, I think that MODE_INDEX_REG_CLASS is a straightforward > generalization of what we have now, but I don't want to approve the > patch over Jeff's head while he has concerns. I'm not quite sure if I know exactly whose court the ball is in at this point. If I understand correctly, Jeff is still unhappy with the patch, and Richard still thinks it's the right thing. So, how do we move forward so that we can get this bug fixed, and wrap up this series of ColdFire patches? Jeff, do have a specific alternative in mind? If I understand correctly, one of the arguments in favor of this patch is that it's symmetric with some of the other macros -- with which you're also unhappy. Perhaps, then, it would be OK to put this in (arguably compounding the damage) with the theory that if we want to make some change later, we can do so wholesale without a whole lot more work than changing the existing bits? Thanks, -- Mark Mitchell CodeSourcery mark@codesourcery.com (650) 331-3385 x713 ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-02-23 9:58 ` Mark Mitchell @ 2007-02-27 0:30 ` Jeffrey Law 2007-02-27 18:55 ` Richard Sandiford 0 siblings, 1 reply; 280+ messages in thread From: Jeffrey Law @ 2007-02-27 0:30 UTC (permalink / raw) To: Mark Mitchell Cc: Bernd Schmidt, Ian Lance Taylor, Richard Sandiford, gcc-patches On Thu, 2007-02-22 at 19:08 -0800, Mark Mitchell wrote: > I'm not quite sure if I know exactly whose court the ball is in at this > point. If I understand correctly, Jeff is still unhappy with the patch, > and Richard still thinks it's the right thing. It's in my court. Current todo is to look at what Bernd did and why and ponder how it plays with what Richard wants to do. I'd also like to see (and this is a new request) some code which triggers these problems. I have a couple theories that I'd like to poke at, but without triggering code that's going to be tough to do. Just to be 100% clear, I want to get this resolved too, but I have concerns that the patch is a terribly bad idea. Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-02-27 0:30 ` Jeffrey Law @ 2007-02-27 18:55 ` Richard Sandiford 2007-02-27 19:02 ` Jeffrey Law 2007-02-27 20:44 ` Jeffrey Law 0 siblings, 2 replies; 280+ messages in thread From: Richard Sandiford @ 2007-02-27 18:55 UTC (permalink / raw) To: law; +Cc: Mark Mitchell, Bernd Schmidt, Ian Lance Taylor, gcc-patches Jeffrey Law <law@redhat.com> writes: > On Thu, 2007-02-22 at 19:08 -0800, Mark Mitchell wrote: >> I'm not quite sure if I know exactly whose court the ball is in at this >> point. If I understand correctly, Jeff is still unhappy with the patch, >> and Richard still thinks it's the right thing. > It's in my court. Current todo is to look at what Bernd did and why > and ponder how it plays with what Richard wants to do. > > I'd also like to see (and this is a new request) some code which > triggers these problems. I have a couple theories that I'd like to > poke at, but without triggering code that's going to be tough to do. OK. I can't remember off-hand which testcases failed without this, so here's a testcase specifically for it: -------------------------------------------------------------------- void foo (float *x); float bar (void) { float x[0x5000]; foo (x); return x[0x4000] + x[0]; } -------------------------------------------------------------------- Compile with -O2 -fomit-frame-pointer -mcpu=5485. Richard ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-02-27 18:55 ` Richard Sandiford @ 2007-02-27 19:02 ` Jeffrey Law 2007-02-27 20:44 ` Jeffrey Law 1 sibling, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-02-27 19:02 UTC (permalink / raw) To: Richard Sandiford Cc: Mark Mitchell, Bernd Schmidt, Ian Lance Taylor, gcc-patches On Tue, 2007-02-27 at 16:50 +0000, Richard Sandiford wrote: > Jeffrey Law <law@redhat.com> writes: > > On Thu, 2007-02-22 at 19:08 -0800, Mark Mitchell wrote: > >> I'm not quite sure if I know exactly whose court the ball is in at this > >> point. If I understand correctly, Jeff is still unhappy with the patch, > >> and Richard still thinks it's the right thing. > > It's in my court. Current todo is to look at what Bernd did and why > > and ponder how it plays with what Richard wants to do. > > > > I'd also like to see (and this is a new request) some code which > > triggers these problems. I have a couple theories that I'd like to > > poke at, but without triggering code that's going to be tough to do. > > OK. I can't remember off-hand which testcases failed without this, > so here's a testcase specifically for it: > > -------------------------------------------------------------------- > void foo (float *x); > float bar (void) > { > float x[0x5000]; > foo (x); > return x[0x4000] + x[0]; > } > -------------------------------------------------------------------- > > Compile with -O2 -fomit-frame-pointer -mcpu=5485. That fails nicely. Thanks. Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-02-27 18:55 ` Richard Sandiford 2007-02-27 19:02 ` Jeffrey Law @ 2007-02-27 20:44 ` Jeffrey Law 2007-02-27 21:44 ` Richard Sandiford ` (2 more replies) 1 sibling, 3 replies; 280+ messages in thread From: Jeffrey Law @ 2007-02-27 20:44 UTC (permalink / raw) To: Richard Sandiford Cc: Mark Mitchell, Bernd Schmidt, Ian Lance Taylor, gcc-patches [-- Attachment #1: Type: text/plain, Size: 3473 bytes --] On Tue, 2007-02-27 at 16:50 +0000, Richard Sandiford wrote: > Jeffrey Law <law@redhat.com> writes: > > On Thu, 2007-02-22 at 19:08 -0800, Mark Mitchell wrote: > >> I'm not quite sure if I know exactly whose court the ball is in at this > >> point. If I understand correctly, Jeff is still unhappy with the patch, > >> and Richard still thinks it's the right thing. > > It's in my court. Current todo is to look at what Bernd did and why > > and ponder how it plays with what Richard wants to do. > > > > I'd also like to see (and this is a new request) some code which > > triggers these problems. I have a couple theories that I'd like to > > poke at, but without triggering code that's going to be tough to do. > > OK. I can't remember off-hand which testcases failed without this, > so here's a testcase specifically for it: > > -------------------------------------------------------------------- > void foo (float *x); > float bar (void) > { > float x[0x5000]; > foo (x); > return x[0x4000] + x[0]; > } > -------------------------------------------------------------------- > > Compile with -O2 -fomit-frame-pointer -mcpu=5485. So after poking at this for a few minutes with the debugger, I'm really interested in why you think fixing double_reg_address_ok to be indexed by the mode of the memory reference is insufficient to fix this problem. Basically we have this after lreg: (insn 24 19 30 2 (set (reg/i:SF 0 %d0 [ <result> ]) (plus:SF (mem/s:SF (plus:SI (reg/f:SI 14 %a6) (const_int -16384 [0xffffc000])) [3 x+65536 S4 A16]) (mem/s:SF (reg/f:SI 31) [3 x+0 S4 A16]))) 157 {addsf3_cf} (nil) (expr_list:REG_DEAD (reg/f:SI 31) (nil))) Which is a valid insn. Register elimination changes the memory reference to something like: (mem:SF (plus:SI (%sp) (const_int 65540)) Which is invalid because the offset is too big. find_reloads_address comes along and realizes the address is invalid and reloads the invalid displacement into an index register creating the (invalid) reg+reg addressing mode via this code: if (double_reg_address_ok) { /* Unshare the sum as well. */ *loc = ad = copy_rtx (ad); /* Reload the displacement into an index reg. We assume the frame pointer or arg pointer is a base reg. */ find_reloads_address_part (XEXP (ad, 1), &XEXP (ad, 1), INDEX_REG_CLASS, GET_MODE (ad), opnum, type, ind_levels); return 0; } The problem, ISTM, is that reload assumes that if reg+reg addressing is valid for QImode (per the double_reg_address_ok computation) then reg+reg addressing must be valid for all modes which is clearly incorrect for coldfire (as well as the PA). If we twiddle reload to made double_reg_address_ok be mode dependent, then instead of reloading the displacement into a register and creating a bogus addressing mode, we'll instead reload the entire sum into a register and use register indirect which is clearly valid. Note you'll still get full use of indexed addressing in cases where your G_I_L_A allows it. I haven't really tested the attached patch except to verify that the provided testcase no longer aborts and that the reloads we generate for the problem insn look correct. However, I feel its a much more correct solution than what you're trying to do. Thoughts/Comments? [-- Attachment #2: DIFFS --] [-- Type: text/x-patch, Size: 4494 bytes --] Index: postreload.c =================================================================== --- postreload.c (revision 122379) +++ postreload.c (working copy) @@ -703,12 +703,15 @@ int last_label_ruid; int min_labelno, n_labels; HARD_REG_SET ever_live_at_start, *label_live; + enum machine_mode mode; /* If reg+reg can be used in offsetable memory addresses, the main chunk of reload has already used it where appropriate, so there is no use in trying to generate it now. */ - if (double_reg_address_ok && INDEX_REG_CLASS != NO_REGS) - return; + for (mode = VOIDmode; (int) mode < NUM_MACHINE_MODES; + mode = (enum machine_mode) ((int) mode + 1)) + if (double_reg_address_ok[mode] && INDEX_REG_CLASS != NO_REGS) + return; /* To avoid wasting too much time later searching for an index register, determine the minimum and maximum index register numbers. */ Index: reload.c =================================================================== --- reload.c (revision 122379) +++ reload.c (working copy) @@ -4965,7 +4965,7 @@ loc = &XEXP (*loc, 0); } - if (double_reg_address_ok) + if (double_reg_address_ok[mode]) { /* Unshare the sum as well. */ *loc = ad = copy_rtx (ad); @@ -5008,8 +5008,8 @@ find_reloads_subreg_address. If we decide to do something, it must be that `double_reg_address_ok' - is true. We generate a reload of the base register + constant and - rework the sum so that the reload register will be added to the index. + is true for MODE. We generate a reload of the base register + constant + and rework the sum so that the reload register will be added to the index. This is safe because we know the address isn't shared. We check for the base register as both the first and second operand of Index: reload.h =================================================================== --- reload.h (revision 122379) +++ reload.h (working copy) @@ -189,7 +189,7 @@ extern char indirect_symref_ok; /* Nonzero if an address (plus (reg frame_pointer) (reg ...)) is valid. */ -extern char double_reg_address_ok; +extern char double_reg_address_ok[MAX_MACHINE_MODE]; extern int num_not_at_initial_offset; Index: reload1.c =================================================================== --- reload1.c (revision 122379) +++ reload1.c (working copy) @@ -244,8 +244,9 @@ which these are valid is the same as spill_indirect_levels, above. */ char indirect_symref_ok; -/* Nonzero if an address (plus (reg frame_pointer) (reg ...)) is valid. */ -char double_reg_address_ok; +/* Nonzero if an address (plus (reg frame_pointer) (reg ...)) is valid, + indxed by the mode of the memory reference. */ +char double_reg_address_ok[MAX_MACHINE_MODE]; /* Record the stack slot for each spilled hard register. */ static rtx spill_stack_slot[FIRST_PSEUDO_REGISTER]; @@ -453,6 +454,7 @@ init_reload (void) { int i; + enum machine_mode mode; /* Often (MEM (REG n)) is still valid even if (REG n) is put on the stack. Set spill_indirect_levels to the number of levels such addressing is @@ -477,24 +479,25 @@ tem = gen_rtx_MEM (Pmode, gen_rtx_SYMBOL_REF (Pmode, "foo")); indirect_symref_ok = memory_address_p (QImode, tem); - /* See if reg+reg is a valid (and offsettable) address. */ + /* See if reg+reg is a valid (and offsettable) address for each mode. */ + for (mode = VOIDmode; (int) mode < NUM_MACHINE_MODES; + mode = (enum machine_mode) ((int) mode + 1)) + for (i = 0; i < FIRST_PSEUDO_REGISTER; i++) + { + tem = gen_rtx_PLUS (Pmode, + gen_rtx_REG (Pmode, HARD_FRAME_POINTER_REGNUM), + gen_rtx_REG (Pmode, i)); - for (i = 0; i < FIRST_PSEUDO_REGISTER; i++) - { - tem = gen_rtx_PLUS (Pmode, - gen_rtx_REG (Pmode, HARD_FRAME_POINTER_REGNUM), - gen_rtx_REG (Pmode, i)); + /* This way, we make sure that reg+reg is an offsettable address. */ + tem = plus_constant (tem, GET_MODE_SIZE (mode)); - /* This way, we make sure that reg+reg is an offsettable address. */ - tem = plus_constant (tem, 4); + if (memory_address_p (mode, tem)) + { + double_reg_address_ok[mode] = 1; + break; + } + } - if (memory_address_p (QImode, tem)) - { - double_reg_address_ok = 1; - break; - } - } - /* Initialize obstack for our rtl allocation. */ gcc_obstack_init (&reload_obstack); reload_startobj = obstack_alloc (&reload_obstack, 0); ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-02-27 20:44 ` Jeffrey Law @ 2007-02-27 21:44 ` Richard Sandiford 2007-02-27 22:34 ` Jeffrey Law 2007-02-28 0:17 ` Ian Lance Taylor 2007-03-01 2:43 ` Roman Zippel 2 siblings, 1 reply; 280+ messages in thread From: Richard Sandiford @ 2007-02-27 21:44 UTC (permalink / raw) To: law; +Cc: Mark Mitchell, Bernd Schmidt, Ian Lance Taylor, gcc-patches Jeffrey Law <law@redhat.com> writes: > On Tue, 2007-02-27 at 16:50 +0000, Richard Sandiford wrote: >> Jeffrey Law <law@redhat.com> writes: >> > On Thu, 2007-02-22 at 19:08 -0800, Mark Mitchell wrote: >> >> I'm not quite sure if I know exactly whose court the ball is in at this >> >> point. If I understand correctly, Jeff is still unhappy with the patch, >> >> and Richard still thinks it's the right thing. >> > It's in my court. Current todo is to look at what Bernd did and why >> > and ponder how it plays with what Richard wants to do. >> > >> > I'd also like to see (and this is a new request) some code which >> > triggers these problems. I have a couple theories that I'd like to >> > poke at, but without triggering code that's going to be tough to do. >> >> OK. I can't remember off-hand which testcases failed without this, >> so here's a testcase specifically for it: >> >> -------------------------------------------------------------------- >> void foo (float *x); >> float bar (void) >> { >> float x[0x5000]; >> foo (x); >> return x[0x4000] + x[0]; >> } >> -------------------------------------------------------------------- >> >> Compile with -O2 -fomit-frame-pointer -mcpu=5485. > So after poking at this for a few minutes with the debugger, I'm really > interested in why you think fixing double_reg_address_ok to be indexed > by the mode of the memory reference is insufficient to fix this problem. Richard Sandiford <richard@codesourcery.com> writes: > Well, I agree making double_reg_address_ok an array of booleans > make sense in principle. However, I think we first need to make > INDEX_REG_CLASS and BASE_REG_CLASS agree with G_I_L_A. (INDEX_REG_CLASS > is supposed to be NO_REGS if indexing isn't supported.) > > Once you do that, there is no current need to make double_reg_address_ok > an array of booleans, and doing so would just make the compiler slightly > slower. So although I agree we should it if some other port needs it > (i.e. if some other port allows disp(base,index) addresses for some > modes and allows only plain (base,index) address for others), I don't > think we should otherwise. And you haven't addressed that point. Do you disagree that INDEX_REG_CLASS is supposed to be NO_REGS if no index regs are allowed? It's not just reload that looks at INDEX_REG_CLASS. > I haven't really tested the attached patch except to verify that > the provided testcase no longer aborts and that the reloads we > generate for the problem insn look correct. However, I feel its a > much more correct solution than what you're trying to do. I honestly don't understand why you think my patch is unreasonable. Richard ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-02-27 21:44 ` Richard Sandiford @ 2007-02-27 22:34 ` Jeffrey Law 2007-02-28 0:57 ` Richard Sandiford 0 siblings, 1 reply; 280+ messages in thread From: Jeffrey Law @ 2007-02-27 22:34 UTC (permalink / raw) To: Richard Sandiford Cc: Mark Mitchell, Bernd Schmidt, Ian Lance Taylor, gcc-patches On Tue, 2007-02-27 at 19:12 +0000, Richard Sandiford wrote: > > > > Once you do that, there is no current need to make double_reg_address_ok > > an array of booleans, and doing so would just make the compiler slightly > > slower. So although I agree we should it if some other port needs it > > (i.e. if some other port allows disp(base,index) addresses for some > > modes and allows only plain (base,index) address for others), I don't > > think we should otherwise. > > And you haven't addressed that point. Do you disagree that INDEX_REG_CLASS > is supposed to be NO_REGS if no index regs are allowed? The validity of indexing is mode dependent on your target. For every mode that allows indexed addressing the set of valid index registers is the same. > > > I haven't really tested the attached patch except to verify that > > the provided testcase no longer aborts and that the reloads we > > generate for the problem insn look correct. However, I feel its a > > much more correct solution than what you're trying to do. > > I honestly don't understand why you think my patch is unreasonable. Because it's not fixing the problem, it's papering over the problem. I am rejecting your patch, over Ian's prior approval. I would ask that you look at the double_reg_address_ok patch -- I'm pretty sure it's a more correct fix. Unfortunately, I don't really have machines suitable for heavy stress testing the patch. jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-02-27 22:34 ` Jeffrey Law @ 2007-02-28 0:57 ` Richard Sandiford 2007-02-28 3:37 ` Jeffrey Law 0 siblings, 1 reply; 280+ messages in thread From: Richard Sandiford @ 2007-02-28 0:57 UTC (permalink / raw) To: law; +Cc: Mark Mitchell, Bernd Schmidt, Ian Lance Taylor, gcc-patches Jeffrey Law <law@redhat.com> writes: > On Tue, 2007-02-27 at 19:12 +0000, Richard Sandiford wrote: >> > >> > Once you do that, there is no current need to make double_reg_address_ok >> > an array of booleans, and doing so would just make the compiler slightly >> > slower. So although I agree we should it if some other port needs it >> > (i.e. if some other port allows disp(base,index) addresses for some >> > modes and allows only plain (base,index) address for others), I don't >> > think we should otherwise. >> >> And you haven't addressed that point. Do you disagree that INDEX_REG_CLASS >> is supposed to be NO_REGS if no index regs are allowed? > The validity of indexing is mode dependent on your target. For every > mode that allows indexed addressing the set of valid index registers > is the same. > > >> >> > I haven't really tested the attached patch except to verify that >> > the provided testcase no longer aborts and that the reloads we >> > generate for the problem insn look correct. However, I feel its a >> > much more correct solution than what you're trying to do. >> >> I honestly don't understand why you think my patch is unreasonable. > Because it's not fixing the problem, it's papering over the problem. I disagree. BASE_REG_CLASS is a guarantee from the backend that any register in that class is a valid base register. Reload relies on that fact. Why should INDEX_REG_CLASS by any different? Richard ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-02-28 0:57 ` Richard Sandiford @ 2007-02-28 3:37 ` Jeffrey Law 2007-02-28 16:17 ` Richard Sandiford 0 siblings, 1 reply; 280+ messages in thread From: Jeffrey Law @ 2007-02-28 3:37 UTC (permalink / raw) To: Richard Sandiford Cc: Mark Mitchell, Bernd Schmidt, Ian Lance Taylor, gcc-patches On Tue, 2007-02-27 at 21:14 +0000, Richard Sandiford wrote: > I disagree. BASE_REG_CLASS is a guarantee from the backend that > any register in that class is a valid base register. Reload relies > on that fact. Why should INDEX_REG_CLASS by any different? Then we disagree. I've explicitly rejected the patch that adds the mode dependent index register class stuff. I believe it is unnecessary and wrong based on working with GCC for more than 15 years, including on targets which have similar characteristics as the coldfire. I've pointed you at a more correct fix. You can pursue that or some other approach. jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-02-28 3:37 ` Jeffrey Law @ 2007-02-28 16:17 ` Richard Sandiford 2007-02-28 19:47 ` Bernd Schmidt 2007-02-28 22:39 ` Jeffrey Law 0 siblings, 2 replies; 280+ messages in thread From: Richard Sandiford @ 2007-02-28 16:17 UTC (permalink / raw) To: law; +Cc: Mark Mitchell, Bernd Schmidt, Ian Lance Taylor, gcc-patches Jeffrey Law <law@redhat.com> writes: > On Tue, 2007-02-27 at 21:14 +0000, Richard Sandiford wrote: >> I disagree. BASE_REG_CLASS is a guarantee from the backend that >> any register in that class is a valid base register. Reload relies >> on that fact. Why should INDEX_REG_CLASS by any different? > Then we disagree. I've explicitly rejected the patch that adds the mode > dependent index register class stuff. I believe it is unnecessary and > wrong based on working with GCC for more than 15 years, including on > targets which have similar characteristics as the coldfire. > > I've pointed you at a more correct fix. You can pursue that or some > other approach. OK, I've tested your patch, and it seems to work fine on ColdFire. I don't think it's correct to use GET_MODE_SIZE as the offset though, because GET_MODE_SIZE is 0 for things like BLKmode. I think the patch would break the elimination of BLKmode addresses on targets like PowerPC that have base+index but not disp+base+index addresses. My concern about efficiency still stands though. Concretely, your patch is going to mean that the MIPS port does (29 modes x 188 regs =) 5452 legitimate address checks at startup, all of which will be false. The figure for PowerPC is (38 modes x 114 regs =) 4332 checks and the figure for ia64 is (40 modes * 334 regs =) 13360 checks. (I realise that ia64 is one of those targets where you expect the compiler to be slower, but still. ;)) As the patch stands, it will also create new garbage addresses for each check. I think at the very least you should: - create one address and use it for all checks, changing parts of it as appropriate - restrict the register loop to members of INDEX_REG_CLASS ...and perhaps skip the loop entirely if INDEX_REG_CLASS is NO_REGS. I notice that you've kept the INDEX_REG_CLASS != NO_REGS check in postreload.c. Given your position on this, do you think that that check is really necessary? I haven't tried to update the patch along these lines because I still want to pitch the original patch as being the correct fix for this problem. Please bear me out here; it comes back to the double_reg_address_ok thing, and I think it provides a neater (more correct) fix for it. My position has been that INDEX_REG_CLASS should be treated as a guarantee that any register of that class is valid as an index register. It seems to me that the relationship between G_I_L_A and *_REG_CLASS is very similar to the relationship between predicates and constraints. On a well-tuned port -- especially one like PowerPC where the predicates enforce class restrictions on hard registers -- the predicates answer the question "is this operand valid?" (or, on less-well-tuned targets, "is this operand reloadable?"), whereas the constraints say "how do I make this operand valid?". I know that's an over-simplification, but I think it is basically true. And it seems to me that G_I_L_A plays the same role as the predicates for addresses -- "is this address valid?", or "is this address reloadable?"[*] -- while *_REG_CLASS-related macros answer the question "how do I make this address valid?". Now it's clearly wrong for an insn's constraints to say X is valid if the predicates reject X, and I don't think we'd consider a patch that was specifically designed to allow such constraints to be used. I think the same should be true of the *_REG_CLASS-related macros. In the code guarded by double_reg_address_ok, reload is trying to create a valid offsetable base+index address. Given the above, I think the *_REG_CLASS group of macros -- the "how do I make this address valid?" macros -- ought to be directly telling reload what class of index register is allowed in such an address. And the backend should answer NO_REGS if it doesn't allow any register to be used like that, much as EXTRA_CONSTRAINT would return NO_REGS for register classes that aren't available with the current command-line options. An obvious way do to this would be add an "offsetable_p" argument to MODE_INDEX_REG_CLASS and mode_reg_class (i.e. the addresses.h function in my patch that wraps the target macros). This approach seems far cleaner to me. The current code, and the code after your patch, is jumping through hoops trying to guess what constitutes an offsetable base+index address, and in which contexts such an address is valid. But this is information that the backend knows a priori. I think adding an "offsetable_p" argument to MODE_INDEX_REG_CLASS would be: - more correct (from my view of the world), because it tallies with the division of labour described above. - more efficient. We would have no need for double_reg_address_ok or its associated start-up code. And in practice, the offsetable_p condition will be eliminated at compile time; the caller will always provide a constant value, and the definitions of the backend macros and mode_index_regs will be trivially foldable. - more forward-looking. I think this is exactly the kind of information that the fabled define_address .md construct would provide. In other words, I think the reload side of the define_address code would directly query the backend in this case, just as my proposal would. Richard [*] ...which isn't necessarily the same thing. E.g. PowerPC (again) deliberately allows out-of-range offsets on eliminable registers, with the knowledge that reload will fix them up if the final register + offset is out of range. ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-02-28 16:17 ` Richard Sandiford @ 2007-02-28 19:47 ` Bernd Schmidt 2007-02-28 22:17 ` Jeffrey Law 2007-02-28 22:39 ` Jeffrey Law 1 sibling, 1 reply; 280+ messages in thread From: Bernd Schmidt @ 2007-02-28 19:47 UTC (permalink / raw) To: law, Mark Mitchell, Bernd Schmidt, Ian Lance Taylor, gcc-patches, richard Richard Sandiford wrote: > In the code guarded by double_reg_address_ok, reload is trying to create > a valid offsetable base+index address. Given the above, I think the > *_REG_CLASS group of macros -- the "how do I make this address valid?" > macros -- ought to be directly telling reload what class of index > register is allowed in such an address. And the backend should answer > NO_REGS if it doesn't allow any register to be used like that, > much as EXTRA_CONSTRAINT would return NO_REGS for register classes > that aren't available with the current command-line options. > An obvious way do to this would be add an "offsetable_p" argument to > MODE_INDEX_REG_CLASS and mode_reg_class (i.e. the addresses.h function > in my patch that wraps the target macros). > > This approach seems far cleaner to me. The current code, and the > code after your patch, is jumping through hoops trying to guess what > constitutes an offsetable base+index address, and in which contexts > such an address is valid. But this is information that the backend knows > a priori. I think adding an "offsetable_p" argument to MODE_INDEX_REG_CLASS > would be: I have to say I agree with Richard. Jeff's patch is certainly good as far as it goes, but to make the target's addressing mode description entirely consistent we'd still need MODE_INDEX_REG_CLASS (although it may well be that it makes no real difference at this point). Once we do that, it seems that double_reg_address_ok could be eliminated in favour of directly using that target macro. Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, Vincent Roche, Joseph E. McDonough ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-02-28 19:47 ` Bernd Schmidt @ 2007-02-28 22:17 ` Jeffrey Law 0 siblings, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-02-28 22:17 UTC (permalink / raw) To: Bernd Schmidt; +Cc: Mark Mitchell, Ian Lance Taylor, gcc-patches, richard On Wed, 2007-02-28 at 14:23 +0100, Bernd Schmidt wrote: > Richard Sandiford wrote: > > > In the code guarded by double_reg_address_ok, reload is trying to create > > a valid offsetable base+index address. Given the above, I think the > > *_REG_CLASS group of macros -- the "how do I make this address valid?" > > macros -- ought to be directly telling reload what class of index > > register is allowed in such an address. And the backend should answer > > NO_REGS if it doesn't allow any register to be used like that, > > much as EXTRA_CONSTRAINT would return NO_REGS for register classes > > that aren't available with the current command-line options. > > An obvious way do to this would be add an "offsetable_p" argument to > > MODE_INDEX_REG_CLASS and mode_reg_class (i.e. the addresses.h function > > in my patch that wraps the target macros). > > > > This approach seems far cleaner to me. The current code, and the > > code after your patch, is jumping through hoops trying to guess what > > constitutes an offsetable base+index address, and in which contexts > > such an address is valid. But this is information that the backend knows > > a priori. I think adding an "offsetable_p" argument to MODE_INDEX_REG_CLASS > > would be: > > I have to say I agree with Richard. Jeff's patch is certainly good as > far as it goes, but to make the target's addressing mode description > entirely consistent we'd still need MODE_INDEX_REG_CLASS (although it > may well be that it makes no real difference at this point). Once we do > that, it seems that double_reg_address_ok could be eliminated in favour > of directly using that target macro. I respectively disagree. For every mode in which indexing is valid on the coldfire, the same set of index registers is valid. INDEX_REG_CLASS should be a constant set of registers in this case and G_I_L_A should simply reject indexing in modes where it is not valid. It's simple and straightforward and does not require introduction mode dependent index register classes. *IF* there was a target where the set of index registers changed based on the mode, then the mode dependent index register class macro would make sense. BUt that's not the case here because the invalid indexing should be rejected by G_I_L_A before we need to worry about the index register being used. I'll repeat, the description is consistent and we do not need mode dependent indexing register descriptions. It's unnecessary and uselessly complicates things. Note that double_reg_address_ok is effectively just an optimization so that reload doesn't have to call into G_I_L_A every time it wants to determine the best way to reload an out of range stack slot address. Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-02-28 16:17 ` Richard Sandiford 2007-02-28 19:47 ` Bernd Schmidt @ 2007-02-28 22:39 ` Jeffrey Law 2007-02-28 22:44 ` Richard Sandiford 1 sibling, 1 reply; 280+ messages in thread From: Jeffrey Law @ 2007-02-28 22:39 UTC (permalink / raw) To: Richard Sandiford Cc: Mark Mitchell, Bernd Schmidt, Ian Lance Taylor, gcc-patches On Wed, 2007-02-28 at 09:22 +0000, Richard Sandiford wrote: > > OK, I've tested your patch, and it seems to work fine on ColdFire. > I don't think it's correct to use GET_MODE_SIZE as the offset though, > because GET_MODE_SIZE is 0 for things like BLKmode. I think the patch > would break the elimination of BLKmode addresses on targets like PowerPC > that have base+index but not disp+base+index addresses. Can you even have a BLKmode indexed address? If you're worried about that, then choose a constant for BLKmode. GET_MODE_SIZE is the correct thing to do for all the other cases. THe previous use of the constant 4 is blatently wrong. The code in question is trying determine offsettability which is defined relative to the size of the mode. > > My concern about efficiency still stands though. Concretely, > your patch is going to mean that the MIPS port does (29 modes x > 188 regs =) 5452 legitimate address checks at startup, all of > which will be false. The figure for PowerPC is (38 modes x 114 regs =) > 4332 checks and the figure for ia64 is (40 modes * 334 regs =) 13360 checks. > (I realise that ia64 is one of those targets where you expect the compiler > to be slower, but still. ;)) As the patch stands, it will also create > new garbage addresses for each check. I think at the very least you > should: > > - create one address and use it for all checks, changing parts of > it as appropriate Definitely. Please go ahead and do this. > > - restrict the register loop to members of INDEX_REG_CLASS Likewise. > > ...and perhaps skip the loop entirely if INDEX_REG_CLASS is NO_REGS. Likewise. I was merely showing a quick proof of concept, it wasn't necessarily meant to go into the tree as-is, but instead show you the way to getting this problem cleanly resolved. Note that the startup efficiency stuff is unfortunate, but the code as it stood was simply wrong. The assumption that if indexing in QImode is valid, then it must be valid for other modes is bogus and we've seen at least two ports which have been broken because of this problem (interestingly enough one of them (coldfire) is a variant of the machine (m68k) the original author probably had in mind when that code was written). > > I notice that you've kept the INDEX_REG_CLASS != NO_REGS check in > postreload.c. Given your position on this, do you think that that > check is really necessary? I was just trying to keep the code reasonably consistent with its prior structure. I've got no problems if you want to change this. > > I haven't tried to update the patch along these lines because > I still want to pitch the original patch as being the correct > fix for this problem. Please bear me out here; it comes back > to the double_reg_address_ok thing, and I think it provides a > neater (more correct) fix for it. No. I _strongly_ feel that patch is wrong. Continuing to argue over it is just wasting everyone's time. Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-02-28 22:39 ` Jeffrey Law @ 2007-02-28 22:44 ` Richard Sandiford 2007-02-28 22:50 ` Mark Mitchell 2007-02-28 22:58 ` Jeffrey Law 0 siblings, 2 replies; 280+ messages in thread From: Richard Sandiford @ 2007-02-28 22:44 UTC (permalink / raw) To: law; +Cc: Mark Mitchell, Bernd Schmidt, Ian Lance Taylor, gcc-patches Jeffrey Law <law@redhat.com> writes: >> My concern about efficiency still stands though. Concretely, >> your patch is going to mean that the MIPS port does (29 modes x >> 188 regs =) 5452 legitimate address checks at startup, all of >> which will be false. The figure for PowerPC is (38 modes x 114 regs =) >> 4332 checks and the figure for ia64 is (40 modes * 334 regs =) 13360 checks. >> (I realise that ia64 is one of those targets where you expect the compiler >> to be slower, but still. ;)) As the patch stands, it will also create >> new garbage addresses for each check. I think at the very least you >> should: >> >> - create one address and use it for all checks, changing parts of >> it as appropriate > Definitely. Please go ahead and do this. Sorry, but I still strongly believe you're leading us in the wrong direction here. I suggest we leave it for someone else with less strong feelings. And... > I was merely showing a quick proof of concept, it wasn't necessarily > meant to go into the tree as-is, but instead show you the way to > getting this problem cleanly resolved. ...with respect Jeff, I didn't need you to tell me how the double_reg_address_ok thing should be implemented. I was resisting doing it because I disagreed with it, not because I didn't understand the concept. Richard ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-02-28 22:44 ` Richard Sandiford @ 2007-02-28 22:50 ` Mark Mitchell 2007-03-01 3:07 ` Roman Zippel 2007-02-28 22:58 ` Jeffrey Law 1 sibling, 1 reply; 280+ messages in thread From: Mark Mitchell @ 2007-02-28 22:50 UTC (permalink / raw) To: law, Mark Mitchell, Bernd Schmidt, Ian Lance Taylor, gcc-patches, richard Richard Sandiford wrote: > Sorry, but I still strongly believe you're leading us in the > wrong direction here. I suggest we leave it for someone else > with less strong feelings. I think that's a good idea. We definitely seem to be at a wall, and tempers are rising. > ...with respect Jeff, I didn't need you to tell me how the > double_reg_address_ok thing should be implemented. I'm sure Jeff meant no insult; he was just trying to be helpful, and respond to my quest that he provide a concrete solution. I think it would be wrong tocheck in Richard's change over Jeff's very strong objections. But, Richard feels that Jeff's idea isn't correct either, and many people seem to agree with Richard. This isn't just a style thing where either side can just say "Oh, well, I don't like it, but let's go along"; both sides are trying to avoid doing damage to the structure of the compiler. So, let's just leave the bug alone for a while. GCC has known bugs; this one isn't going to be fatal. We can always fix it before 4.3, with either of the available solutions, if we decide we want to do so. Maybe Ian, Bernd, or others can read back over the thread and offer an opinion, addressing the objections of both parties. -- Mark Mitchell CodeSourcery mark@codesourcery.com (650) 331-3385 x713 ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-02-28 22:50 ` Mark Mitchell @ 2007-03-01 3:07 ` Roman Zippel 2007-03-01 5:11 ` Mark Mitchell 0 siblings, 1 reply; 280+ messages in thread From: Roman Zippel @ 2007-03-01 3:07 UTC (permalink / raw) To: Mark Mitchell; +Cc: law, Bernd Schmidt, Ian Lance Taylor, gcc-patches, richard Hi, On Wed, 28 Feb 2007, Mark Mitchell wrote: > So, let's just leave the bug alone for a while. GCC has known bugs; > this one isn't going to be fatal. We can always fix it before 4.3, with > either of the available solutions, if we decide we want to do so. Maybe > Ian, Bernd, or others can read back over the thread and offer an > opinion, addressing the objections of both parties. The problem is that a number of important patches currently depend on it (e.g. we badly need the m68k_decompose_address function or the rtx prologue/epilogue) and I really would like to see some of this also in 4.2. It should be possible to rework the patches, but we shouldn't wait too long with a decision on how to proceed... bye, Roman ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-03-01 3:07 ` Roman Zippel @ 2007-03-01 5:11 ` Mark Mitchell 0 siblings, 0 replies; 280+ messages in thread From: Mark Mitchell @ 2007-03-01 5:11 UTC (permalink / raw) To: Roman Zippel; +Cc: law, Bernd Schmidt, Ian Lance Taylor, gcc-patches, richard Roman Zippel wrote: > The problem is that a number of important patches currently depend on it > (e.g. we badly need the m68k_decompose_address function or the rtx > prologue/epilogue) and I really would like to see some of this also in > 4.2. None of these changes are appropriate for 4.2. So, there really is no hurry. Sorry, -- Mark Mitchell CodeSourcery mark@codesourcery.com (650) 331-3385 x713 ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-02-28 22:44 ` Richard Sandiford 2007-02-28 22:50 ` Mark Mitchell @ 2007-02-28 22:58 ` Jeffrey Law 1 sibling, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-02-28 22:58 UTC (permalink / raw) To: Richard Sandiford Cc: Mark Mitchell, Bernd Schmidt, Ian Lance Taylor, gcc-patches On Wed, 2007-02-28 at 16:34 +0000, Richard Sandiford wrote: > Jeffrey Law <law@redhat.com> writes: > >> My concern about efficiency still stands though. Concretely, > >> your patch is going to mean that the MIPS port does (29 modes x > >> 188 regs =) 5452 legitimate address checks at startup, all of > >> which will be false. The figure for PowerPC is (38 modes x 114 regs =) > >> 4332 checks and the figure for ia64 is (40 modes * 334 regs =) 13360 checks. > >> (I realise that ia64 is one of those targets where you expect the compiler > >> to be slower, but still. ;)) As the patch stands, it will also create > >> new garbage addresses for each check. I think at the very least you > >> should: > >> > >> - create one address and use it for all checks, changing parts of > >> it as appropriate > > Definitely. Please go ahead and do this. > > Sorry, but I still strongly believe you're leading us in the > wrong direction here. I suggest we leave it for someone else > with less strong feelings. And... I have strong feelings because I'm more than familiar with the code in question. I'm going to object if someone tries to install your patch. It's unnecessary and papering over the bogus code which computes double_reg_address_ok. You have a path by which you can get the coldfire problems resolved cleanly, would you please take it rather than continuing to argue for the original patch. jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-02-27 20:44 ` Jeffrey Law 2007-02-27 21:44 ` Richard Sandiford @ 2007-02-28 0:17 ` Ian Lance Taylor 2007-02-28 0:21 ` Jeffrey Law 2007-03-01 2:43 ` Roman Zippel 2 siblings, 1 reply; 280+ messages in thread From: Ian Lance Taylor @ 2007-02-28 0:17 UTC (permalink / raw) To: law; +Cc: Richard Sandiford, Mark Mitchell, Bernd Schmidt, gcc-patches Jeffrey Law <law@redhat.com> writes: > The problem, ISTM, is that reload assumes that if reg+reg addressing > is valid for QImode (per the double_reg_address_ok computation) then > reg+reg addressing must be valid for all modes which is clearly > incorrect for coldfire (as well as the PA). If we twiddle reload > to made double_reg_address_ok be mode dependent, then instead of > reloading the displacement into a register and creating a bogus > addressing mode, we'll instead reload the entire sum into a register > and use register indirect which is clearly valid. Note you'll still > get full use of indexed addressing in cases where your G_I_L_A > allows it. The thing I think is odd about this approach is that as far as I know reg+reg addressing is not actually mode dependent; it's dependent on the register class which is the destination of the load. We are using the mode as a proxy for that. In principle we can do better. > I haven't really tested the attached patch except to verify that > the provided testcase no longer aborts and that the reloads we > generate for the problem insn look correct. However, I feel its a > much more correct solution than what you're trying to do. I think you forgot to attach the patch. Ian ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-02-28 0:17 ` Ian Lance Taylor @ 2007-02-28 0:21 ` Jeffrey Law 2007-03-01 3:14 ` Roman Zippel 0 siblings, 1 reply; 280+ messages in thread From: Jeffrey Law @ 2007-02-28 0:21 UTC (permalink / raw) To: Ian Lance Taylor Cc: Richard Sandiford, Mark Mitchell, Bernd Schmidt, gcc-patches [-- Attachment #1: Type: text/plain, Size: 942 bytes --] On Tue, 2007-02-27 at 12:24 -0800, Ian Lance Taylor wrote: > Jeffrey Law <law@redhat.com> writes: > The thing I think is odd about this approach is that as far as I know > reg+reg addressing is not actually mode dependent; it's dependent on > the register class which is the destination of the load. We are using > the mode as a proxy for that. In principle we can do better. True. I'm well aware that I'm glossing over that. GCC as a whole really falls down when address validity has that level of context dependency. The PA is notorious in this regard and the problems just about drove me nuts. Even with that caveat, I still think fixing how we use double_reg_address_ok is a much better fix and removes one of reload's (incorrect) assumptions about how addressing modes can be used (if indexing is valid for QImode, then it must be valid for other modes). > I think you forgot to attach the patch. > Not my day. Attached [-- Attachment #2: DIFFS --] [-- Type: text/x-patch, Size: 4494 bytes --] Index: postreload.c =================================================================== --- postreload.c (revision 122379) +++ postreload.c (working copy) @@ -703,12 +703,15 @@ int last_label_ruid; int min_labelno, n_labels; HARD_REG_SET ever_live_at_start, *label_live; + enum machine_mode mode; /* If reg+reg can be used in offsetable memory addresses, the main chunk of reload has already used it where appropriate, so there is no use in trying to generate it now. */ - if (double_reg_address_ok && INDEX_REG_CLASS != NO_REGS) - return; + for (mode = VOIDmode; (int) mode < NUM_MACHINE_MODES; + mode = (enum machine_mode) ((int) mode + 1)) + if (double_reg_address_ok[mode] && INDEX_REG_CLASS != NO_REGS) + return; /* To avoid wasting too much time later searching for an index register, determine the minimum and maximum index register numbers. */ Index: reload.c =================================================================== --- reload.c (revision 122379) +++ reload.c (working copy) @@ -4965,7 +4965,7 @@ loc = &XEXP (*loc, 0); } - if (double_reg_address_ok) + if (double_reg_address_ok[mode]) { /* Unshare the sum as well. */ *loc = ad = copy_rtx (ad); @@ -5008,8 +5008,8 @@ find_reloads_subreg_address. If we decide to do something, it must be that `double_reg_address_ok' - is true. We generate a reload of the base register + constant and - rework the sum so that the reload register will be added to the index. + is true for MODE. We generate a reload of the base register + constant + and rework the sum so that the reload register will be added to the index. This is safe because we know the address isn't shared. We check for the base register as both the first and second operand of Index: reload.h =================================================================== --- reload.h (revision 122379) +++ reload.h (working copy) @@ -189,7 +189,7 @@ extern char indirect_symref_ok; /* Nonzero if an address (plus (reg frame_pointer) (reg ...)) is valid. */ -extern char double_reg_address_ok; +extern char double_reg_address_ok[MAX_MACHINE_MODE]; extern int num_not_at_initial_offset; Index: reload1.c =================================================================== --- reload1.c (revision 122379) +++ reload1.c (working copy) @@ -244,8 +244,9 @@ which these are valid is the same as spill_indirect_levels, above. */ char indirect_symref_ok; -/* Nonzero if an address (plus (reg frame_pointer) (reg ...)) is valid. */ -char double_reg_address_ok; +/* Nonzero if an address (plus (reg frame_pointer) (reg ...)) is valid, + indxed by the mode of the memory reference. */ +char double_reg_address_ok[MAX_MACHINE_MODE]; /* Record the stack slot for each spilled hard register. */ static rtx spill_stack_slot[FIRST_PSEUDO_REGISTER]; @@ -453,6 +454,7 @@ init_reload (void) { int i; + enum machine_mode mode; /* Often (MEM (REG n)) is still valid even if (REG n) is put on the stack. Set spill_indirect_levels to the number of levels such addressing is @@ -477,24 +479,25 @@ tem = gen_rtx_MEM (Pmode, gen_rtx_SYMBOL_REF (Pmode, "foo")); indirect_symref_ok = memory_address_p (QImode, tem); - /* See if reg+reg is a valid (and offsettable) address. */ + /* See if reg+reg is a valid (and offsettable) address for each mode. */ + for (mode = VOIDmode; (int) mode < NUM_MACHINE_MODES; + mode = (enum machine_mode) ((int) mode + 1)) + for (i = 0; i < FIRST_PSEUDO_REGISTER; i++) + { + tem = gen_rtx_PLUS (Pmode, + gen_rtx_REG (Pmode, HARD_FRAME_POINTER_REGNUM), + gen_rtx_REG (Pmode, i)); - for (i = 0; i < FIRST_PSEUDO_REGISTER; i++) - { - tem = gen_rtx_PLUS (Pmode, - gen_rtx_REG (Pmode, HARD_FRAME_POINTER_REGNUM), - gen_rtx_REG (Pmode, i)); + /* This way, we make sure that reg+reg is an offsettable address. */ + tem = plus_constant (tem, GET_MODE_SIZE (mode)); - /* This way, we make sure that reg+reg is an offsettable address. */ - tem = plus_constant (tem, 4); + if (memory_address_p (mode, tem)) + { + double_reg_address_ok[mode] = 1; + break; + } + } - if (memory_address_p (QImode, tem)) - { - double_reg_address_ok = 1; - break; - } - } - /* Initialize obstack for our rtl allocation. */ gcc_obstack_init (&reload_obstack); reload_startobj = obstack_alloc (&reload_obstack, 0); ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-02-28 0:21 ` Jeffrey Law @ 2007-03-01 3:14 ` Roman Zippel 0 siblings, 0 replies; 280+ messages in thread From: Roman Zippel @ 2007-03-01 3:14 UTC (permalink / raw) To: Jeffrey Law Cc: Ian Lance Taylor, Richard Sandiford, Mark Mitchell, Bernd Schmidt, gcc-patches Hi, On Tue, 27 Feb 2007, Jeffrey Law wrote: > Even with that caveat, I still think fixing how we use > double_reg_address_ok is a much better fix and removes > one of reload's (incorrect) assumptions about how addressing > modes can be used (if indexing is valid for QImode, then it > must be valid for other modes). I think nobody disagrees that double_reg_address_ok is problematic, but as Bernd mentions it could be replaced with MODE_INDEX_REG_CLASS. bye, Roman ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-02-27 20:44 ` Jeffrey Law 2007-02-27 21:44 ` Richard Sandiford 2007-02-28 0:17 ` Ian Lance Taylor @ 2007-03-01 2:43 ` Roman Zippel 2 siblings, 0 replies; 280+ messages in thread From: Roman Zippel @ 2007-03-01 2:43 UTC (permalink / raw) To: Jeffrey Law Cc: Richard Sandiford, Mark Mitchell, Bernd Schmidt, Ian Lance Taylor, gcc-patches Hi, On Tue, 27 Feb 2007, Jeffrey Law wrote: > So after poking at this for a few minutes with the debugger, I'm really > interested in why you think fixing double_reg_address_ok to be indexed > by the mode of the memory reference is insufficient to fix this problem. I don't want to judge which patch is better, but I still don't understand what's so wrong with Richard's approach. What you basically seem to say is that MODE_BASE_REG_CLASS is ok, because we can't that easily work around it in the generic code. Your patch is not that different - it adds a mode argument to the index register (it just differs how it's done), something you were quite opposed to previously. Additionally your patch only addresses a specific case, which opens the question, whether it might be needed in other places as well. Actually some of your arguments can be used equally against your patch. Specifically that integer register can hold fp values and vice versa. Let's assume we want to allow an index in some modes, e.g. for memory-memory moves or where we know it's an integer register (e.g. the previous function return value in %d0), thus in examples like this we can determine quite early whether the indexed mode is beneficial: float g1(void); void f1(float *p, int i) { p[i] = g1(); } void g2(float); void f2(float *p, int i) { g2(p[i]); } This means G_I_L_A would become more permissive and your change becomes unnecessary (all double_reg_address_ok values are true), but it also means reload would be able to solve the stack register problem by using an integer register as reload register. At this point it would also become permissive to LEGITIMIZE_RELOAD_ADDRESS to generate a better reload and IMO this makes the usage restrictions on LEGITIMIZE_RELOAD_ADDRESS hair-splitting - yes, it was initially meant as optimization, but what evil does it do to also use it to fix addresses generated by reload itself? Anyway, while I like this idea to allow a few more addressing modes if possible, I think it's more a long term option, as it requires many predicate adjustments in m68k.md. I would also like to mention another possible option I brought up earlier. Since reloads for memory operands are done quite early, it's almost impossible to produce the most efficient reload, as it depends on the selected instruction which addressing mode can be used, e.g. in our fp stack value example the following instruction sequences are theoretically possible: move.l #-0x10000,%d0 move.l (%fp,%d0),-(%sp) or move.l %fp,%a0 add.l #-0x10000,%a0 fmove.s (%a0),%fp0 As seen in the last example the tendency of reload to prefer the indexed mode is not always beneficial and to make things a little more complex - the index mode on ColdFire is actually even more restricted as it can only be used once per instruction, so for an example like this: (set (mem (plus (reg %a1) (reg %d1))) (mem (plus (reg %fp) (const_int -0x10000))) reload currently generates something like this move.l #-0x10000,%d0 move.l (%fp,%d0),%d0 move.l %d0,(%a1,%d1) whereas the following is two bytes shorter move.l %fp,%a0 add.l #-0x10000,%a0 move.l (%a0),(%a1,%d1) So in order to improve the reload handling for this, we could use the constraints of the instruction, but this means we need to delay the reload of memory operands (or at least part of it) in find_reloads(), which looks doable, but someone more familiar needs to comment on this. OTOH this could also cleanup all the current base/register handling based on the mode and give us more flexibility, as it can be controlled per instruction. bye, Roman ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-02-14 17:48 ` Ian Lance Taylor 2007-02-15 12:48 ` Bernd Schmidt @ 2007-02-27 20:22 ` Jeffrey Law 1 sibling, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-02-27 20:22 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: Richard Sandiford, gcc-patches, mark On Wed, 2007-02-14 at 09:47 -0800, Ian Lance Taylor wrote: > Richard Sandiford <richard@codesourcery.com> writes: > > > @defmac MODE_CODE_BASE_REG_CLASS (@var{mode}, @var{outer_code}, @var{index_code}) > > Oh yeah, MODE_CODE_BASE_REG_CLASS came in here, written and committed > by Bernd: > http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01952.html Thanks. It looks like the introduction of MODE_CODE_BASE_REG_CLASS was OK based on the blackfin problem Bernd was trying to fix. It appears to me that the blackfin has different sets of valid base registers depending on the type of addressing (reg+d vs postinc). Note this is different from the set of problems we're running into on the coldfire. jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-02-14 17:37 ` Richard Sandiford 2007-02-14 17:48 ` Ian Lance Taylor @ 2007-02-27 20:25 ` Jeffrey Law 1 sibling, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-02-27 20:25 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches, mark On Wed, 2007-02-14 at 17:31 +0000, Richard Sandiford wrote: > > modes. > > Well, I agree making double_reg_address_ok an array of booleans > make sense in principle. However, I think we first need to make > INDEX_REG_CLASS and BASE_REG_CLASS agree with G_I_L_A. (INDEX_REG_CLASS > is supposed to be NO_REGS if indexing isn't supported.) But the issue here isn't that some index registers are valid in some cases and not in others. The issue is that indexing as a whole is valid in some cases and not others. > > Once you do that, there is no current need to make double_reg_address_ok > an array of booleans, and doing so would just make the compiler slightly > slower. So although I agree we should it if some other port needs it > (i.e. if some other port allows disp(base,index) addresses for some > modes and allows only plain (base,index) address for others), I don't > think we should otherwise. But I strongly feel that "fixing" INDEX_REG_CLASS is just papering over the bogus double_reg_address_ok bits. I really wish I had pushed on getting double_reg_address_ok fixed eons ago, but it was a different time and a different development environment. If we look at the MODE_BASE_blah macros they were introduced to deal with different problems. For the thumb the set of valid base registers differs based on the mode of the memory reference. Note that indexing is still valid, only the set of valid base registers changes. For the blackfin the set of valid registers changes based on the type of memory reference as well (reg+d vs autoinc). The coldfire issue is completely and totally different. For the coldfire the set of valid index registers does not change. ie, every mode that allows indexing allows the same set of index registers. But you're trying to use that hook to deal with your coldfire issues (where indexing is simply not allowed in some modes). More shortly... Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-02-14 17:14 ` Jeffrey Law 2007-02-14 17:31 ` Ian Lance Taylor 2007-02-14 17:37 ` Richard Sandiford @ 2007-02-14 19:10 ` Roman Zippel 2 siblings, 0 replies; 280+ messages in thread From: Roman Zippel @ 2007-02-14 19:10 UTC (permalink / raw) To: Jeffrey Law; +Cc: Richard Sandiford, gcc-patches, mark Hi, On Wed, 14 Feb 2007, Jeffrey Law wrote: > > So, _from an optimisation perspective_, I think it is reasonable to > > accept indexed addresses for SImode and not for SFmode. I'm still > > not sure whether you disagree with that. > I disagree with that if the port allows integer values in FP regsters > and the hardware can't do FP indexed loads/stores because G_I_L_A > could be passed SImode but generate an FP load/store. m68k doesn't allow integer values in fp register (rejected in m68k_regno_mode_ok), thus... > > Now G_I_L_A has a mode argument _precisely_ so that the legitimacy of > > an address can depend on the mode. However, G_I_L_A is not the only > > backend interface for describing addressing modes; we also have the > > BASE_REG_CLASS and INDEX_REG_CLASS macros. These latter macros are > > all that reload looks at when legitimizing addresses, so they must > > of course agree with G_I_L_A. > I disagree on this point and as I've stated before I think you're > using this to avoid fixing the backend to deal with a broken G_I_L_A. ...our G_I_L_A isn't broken in this regard. bye, Roman ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-01-10 11:23 ` [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro Richard Sandiford 2007-01-10 11:24 ` [ColdFire 25/63] Define MODE_INDEX_REG_CLASS for m68k Richard Sandiford 2007-01-10 19:30 ` [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro Jeffrey Law @ 2007-01-12 15:45 ` Ian Lance Taylor 2007-01-15 18:05 ` Jeffrey Law 2 siblings, 1 reply; 280+ messages in thread From: Ian Lance Taylor @ 2007-01-12 15:45 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches, mark Richard Sandiford <richard@codesourcery.com> writes: > At the moment, gcc expects there to be a single INDEX_REG_CLASS that > applies to all MEM modes. This is not true when using a ColdFire FPU, > as index registers are not allowed for floating-point modes. The port > tries to hack around this by using "<Q>U" instead of "m" in the movsf > constraints, but that's only a half solution. If reload has to reload > an indexed MEM (rather than the MEM's address), it will expect that > instruction to match. > > The fix is to allow the class of index register to vary depending on > the mode of the addressed value, as the base register class already can. > > This patch does the target-independent bit. It adds new target macros > called MODE_INDEX_REG_CLASS and REGNO_MODE_OK_FOR_INDEX_P, to accompany > the existing MODE_BASE_REG_CLASS and REGNO_MODE_OK_FOR_BASE_P. It also > defines index equivalents of the addresses.h base functions. This is > all a direct image of the base register code (including the wording > of comments and documentation). I think the two should be consistent. > The patch then adjusts all code to use thse new addresses.h functions. You know, when MODE_CODE_BASE_REG_CLASS went in I said "you know, this stuff is getting kind of complicated, we should get some sort of unified approach, just wait until we have mode dependent index registers" and everybody said "ha ha ha, that Ian, what a joke, not even a DSP hardware designer would invent *mode dependent index regs*" and I scowled and tried to hit them with my cane but they were too fast for me, the young whippersnappers. So all I have to say to them is "LOOK WHO'S LAUGHING NOW" oh and also I have to say "so when are we going to see MODE_CODE_INDEX_REG_CLASS? Now what do you think about a unified approach?" > gcc/ > * Makefile.in (postreload.o): Depend on addresses.h. > * addresses.h (index_reg_class, ok_for_index_p_1): New functions. > (regno_ok_for_index_p): New function. > * postreload.c: Include addresses.h. > (reload_combine): Use index_reg_class instead of INDEX_REG_CLASS. > * regclass.c (ok_for_index_p_nonstrict): Add a mode argument. > Use ok_for_index_p_1 instead of REGNO_OK_FOR_INDEX_P. > (record_address_regs): Use index_reg_class instead of INDEX_REG_CLASS. > Update calls to ok_for_index_p_nonstrict. > * regrename.c (scan_rtx_address): Use regno_ok_for_index_p instead of > REGNO_OK_FOR_INDEX_P and index_reg_class instead of INDEX_REG_CLASS. > (replace_oldest_value_addr): Likewise. > * reload.c (find_reloads_address): Use index_reg_class instead > of INDEX_REG_CLASS. Do not push an index register reload if > index_reg_class returns NO_REGS. > (find_reloads_address_1): Use index_reg_class instead > of INDEX_REG_CLASS and regno_ok_for_index_p instead of > REGNO_OK_FOR_INDEX_P. > * doc/tm.texi (MODE_INDEX_REG_CLASS): Document new macro. > (REGNO_MODE_OK_FOR_INDEX_P): Likewise. This patch is OK, grumble, grumble, grumble. Ian ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro 2007-01-12 15:45 ` Ian Lance Taylor @ 2007-01-15 18:05 ` Jeffrey Law 0 siblings, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-01-15 18:05 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: Richard Sandiford, gcc-patches, mark On Fri, 2007-01-12 at 07:44 -0800, Ian Lance Taylor wrote: > You know, when MODE_CODE_BASE_REG_CLASS went in I said "you know, this > stuff is getting kind of complicated, we should get some sort of > unified approach, just wait until we have mode dependent index > registers" and everybody said "ha ha ha, that Ian, what a joke, not > even a DSP hardware designer would invent *mode dependent index regs*" > and I scowled and tried to hit them with my cane but they were too > fast for me, the young whippersnappers. > > So all I have to say to them is "LOOK WHO'S LAUGHING NOW" oh and also > I have to say "so when are we going to see MODE_CODE_INDEX_REG_CLASS? > Now what do you think about a unified approach?" The PA has made "mode" dependent indexing for, umm, approaching 20 years now. Specifically, indexed addressing is available for loads from memory into integer or FP registers and for stores from FP registers into memory, but not for stores from integer registers into memory. The problem is selecting on the mode (SImode, DFmode, SFmode, etc) is wrong as the GCC mode does not imply that we'll be using a particular register file (integer vs FP) for the register operand. To fix this class of problems we need to know what register file is going to be used for the register operand, and that's not necessarily available at the time we need it. Richard's patch, while seemingly good depends heavily on the backend disallowing certain operations (specifically loads/stores of integer modes using FP regs and FP modes using integer registers). jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 23/63] Some assorted cleanups 2007-01-10 11:21 ` [ColdFire 23/63] Some assorted cleanups Richard Sandiford 2007-01-10 11:23 ` [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro Richard Sandiford @ 2007-01-10 18:43 ` Jeffrey Law 1 sibling, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-01-10 18:43 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches On Wed, 2007-01-10 at 11:21 +0000, Richard Sandiford wrote: > A few assorted, minor cleanups. > > Richard > gcc/ > 200x-xx-xx Nathan Sidwell <nathan@codesourcery.com> > > * config/m68k/m68k.h (REGISTER_MOVE_COST): Simplify definition. > (STACK_GROWS_DOWNWARD): Define to 1. > (FUNCTION_VALUE, LIBCALL_VALUE, FUNCTION_VALUE_REGNO_P): Equivocate > comments, emphasizing that these values are only defaults. > * config/m68k/linux.h (LINK_SPEC): Fix formatting in #undef. > * config/m68k/m68k.c (const_method): Remove trailing whitespace. OK. Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 22/63] Remove redundant PIC handling 2007-01-10 11:20 ` [ColdFire 22/63] Remove redundant PIC handling Richard Sandiford 2007-01-10 11:21 ` [ColdFire 23/63] Some assorted cleanups Richard Sandiford @ 2007-01-10 18:41 ` Jeffrey Law 2007-01-10 21:42 ` Richard Sandiford 1 sibling, 1 reply; 280+ messages in thread From: Jeffrey Law @ 2007-01-10 18:41 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches On Wed, 2007-01-10 at 11:20 +0000, Richard Sandiford wrote: > The comment for cmpsi claims that it too needs to handle illegitimate > constant operands, in much the same way as movsi does. This may have > been true in the old days, but I don't think it is now. This patch > removes the comment and associated code. Note that the comment above > movsi doesn't need any adjusting; it doesn't refer to cmpsi. > > The patch also adds a PIC testcase that failed at one stage during > the original development process. > > Richard > > > gcc/ > * config/m68k/m68k.md (cmpsi): Remove outdated flag_pic handling. > > gcc/testsuite/ > 200x-xx-xx Nathan Sidwell <nathan@codesourcery.com> > > * gcc.dg/m68k-pic-1.c: New. I don't recall specifically (it's only been 15+ years) why we need to intercept cmpsi, but it was certainly necessary. I'd like to see some explanation why you think it's no longer necessary before removing that code. Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 22/63] Remove redundant PIC handling 2007-01-10 18:41 ` [ColdFire 22/63] Remove redundant PIC handling Jeffrey Law @ 2007-01-10 21:42 ` Richard Sandiford 2007-01-10 22:18 ` Jeffrey Law 0 siblings, 1 reply; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 21:42 UTC (permalink / raw) To: law; +Cc: gcc-patches Jeffrey Law <law@redhat.com> writes: > On Wed, 2007-01-10 at 11:20 +0000, Richard Sandiford wrote: >> The comment for cmpsi claims that it too needs to handle illegitimate >> constant operands, in much the same way as movsi does. This may have >> been true in the old days, but I don't think it is now. This patch >> removes the comment and associated code. Note that the comment above >> movsi doesn't need any adjusting; it doesn't refer to cmpsi. >> >> The patch also adds a PIC testcase that failed at one stage during >> the original development process. >> >> Richard >> >> >> gcc/ >> * config/m68k/m68k.md (cmpsi): Remove outdated flag_pic handling. >> >> gcc/testsuite/ >> 200x-xx-xx Nathan Sidwell <nathan@codesourcery.com> >> >> * gcc.dg/m68k-pic-1.c: New. > I don't recall specifically (it's only been 15+ years) why we need to > intercept cmpsi, ;) > but it was certainly necessary. I'd like to see some explanation why > you think it's no longer necessary before removing that code. These days we enforce the predicates of cmpsi, like we do for other optabs. The pattern is: --------------------------------------------------------------------------- (define_expand "cmpsi" [(set (cc0) (compare (match_operand:SI 0 "nonimmediate_operand" "") (match_operand:SI 1 "general_operand" "")))] --------------------------------------------------------------------------- so we should only see nonimmediate_operands and general_operands in the expander. E.g., emit_cmp_and_jump_insn_1 says: --------------------------------------------------------------------------- /* Handle compares for which there is a directly suitable insn. */ icode = (int) cmp_optab->handlers[(int) wider_mode].insn_code; if (icode != CODE_FOR_nothing) { x = prepare_operand (icode, x, 0, mode, wider_mode, unsignedp); y = prepare_operand (icode, y, 1, mode, wider_mode, unsignedp); emit_insn (GEN_FCN (icode) (x, y)); if (label) emit_jump_insn (bcc_gen_fctn[(int) comparison] (label)); return; } --------------------------------------------------------------------------- where prepare_operand forces everything that doesn't match the predicate into a register: --------------------------------------------------------------------------- if (!insn_data[icode].operand[opnum].predicate (x, insn_data[icode].operand[opnum].mode)) { if (no_new_pseudos) return NULL_RTX; x = copy_to_mode_reg (insn_data[icode].operand[opnum].mode, x); } --------------------------------------------------------------------------- This copy_to_mode_reg will indirectly call the move expanders to legitimize illegitimate operands. (And symbolic constants _are_ illegitimate operands for flag_pic && !TARGET_PCREL because of LEGITIMATE_PIC_OPERAND_P.) gen_cond_trap does a similar thing to emit_cmp_and_jump_insn_1. Richard ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 22/63] Remove redundant PIC handling 2007-01-10 21:42 ` Richard Sandiford @ 2007-01-10 22:18 ` Jeffrey Law 0 siblings, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-01-10 22:18 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches On Wed, 2007-01-10 at 21:42 +0000, Richard Sandiford wrote: > These days we enforce the predicates of cmpsi, like we do for other > optabs. The pattern is: Ah. Yes, that is causing some old neurons to fire... There was a problem with not checking predicates for movsi/cmpsi expanders (and probably movdi/cmpdi for 64bit targets). > --------------------------------------------------------------------------- > if (!insn_data[icode].operand[opnum].predicate > (x, insn_data[icode].operand[opnum].mode)) > { > if (no_new_pseudos) > return NULL_RTX; > x = copy_to_mode_reg (insn_data[icode].operand[opnum].mode, x); > } > --------------------------------------------------------------------------- > > This copy_to_mode_reg will indirectly call the move expanders to > legitimize illegitimate operands. (And symbolic constants _are_ > illegitimate operands for flag_pic && !TARGET_PCREL because of > LEGITIMATE_PIC_OPERAND_P.) Yea, this sequence will ultimately result in calling the movsi expander to get the non-general operand into a register which will trigger a PIC sequence. Thanks for walking me through it. The patch is OK with me now :-) Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 21/63] Add *_REGNO_P macros 2007-01-10 11:19 ` [ColdFire 21/63] Add *_REGNO_P macros Richard Sandiford 2007-01-10 11:20 ` [ColdFire 22/63] Remove redundant PIC handling Richard Sandiford @ 2007-01-10 17:55 ` Jeffrey Law 2007-01-15 18:51 ` Roman Zippel 2 siblings, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-01-10 17:55 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches On Wed, 2007-01-10 at 11:19 +0000, Richard Sandiford wrote: > The m68k port has cryptic conditions like: > > (REGNO (X) ^ 020) >= 8 > > (which checks whether something is not a hard floating-point register). > This patch replaces them with more readable *_REGNO_P macros, > which are then used by later patches in the series. > > The patch also replaces a hard-coded 8 with A0_REG. > > Richard > > > gcc/ > 200x-xx-xx Kazu Hirata <kazu@codesourcery.com> > Richard Sandiford <richard@codesourcery.com> > > * config/m68k/m68k.h (DATA_REGNO_P, ADDRESS_REGNO_P, INT_REGNO_P) > (FP_REGNO_P): New macros. > (REGNO_OK_FOR_INDEX_P, REGNO_OK_FOR_BASE_P, REGNO_OK_FOR_DATA_P) > (REGNO_OK_FOR_FP_P, REG_OK_FOR_INDEX_P, REG_OK_FOR_BASE_P): Use them. > (EH_RETURN_STACKADJ_RTX): Use A0_REG. > * config/m68k/m68k.c (m68k_regno_mode_ok): Use the new REGNO macros. OK. jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 21/63] Add *_REGNO_P macros 2007-01-10 11:19 ` [ColdFire 21/63] Add *_REGNO_P macros Richard Sandiford 2007-01-10 11:20 ` [ColdFire 22/63] Remove redundant PIC handling Richard Sandiford 2007-01-10 17:55 ` [ColdFire 21/63] Add *_REGNO_P macros Jeffrey Law @ 2007-01-15 18:51 ` Roman Zippel 2 siblings, 0 replies; 280+ messages in thread From: Roman Zippel @ 2007-01-15 18:51 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches Hi, On Wed, 10 Jan 2007, Richard Sandiford wrote: > Index: gcc/config/m68k/m68k.h > =================================================================== > --- gcc/config/m68k/m68k.h 2007-01-09 15:02:02.000000000 +0000 > +++ gcc/config/m68k/m68k.h 2007-01-09 15:02:04.000000000 +0000 > @@ -741,14 +741,33 @@ #define HAVE_PRE_DECREMENT 1 > > /* Macros to check register numbers against specific register classes. */ > > -#define REGNO_OK_FOR_INDEX_P(REGNO) \ > -((REGNO) < 16 || (unsigned) reg_renumber[REGNO] < 16) > -#define REGNO_OK_FOR_BASE_P(REGNO) \ > -(((REGNO) ^ 010) < 8 || (unsigned) (reg_renumber[REGNO] ^ 010) < 8) > -#define REGNO_OK_FOR_DATA_P(REGNO) \ > -((REGNO) < 8 || (unsigned) reg_renumber[REGNO] < 8) > -#define REGNO_OK_FOR_FP_P(REGNO) \ > -(((REGNO) ^ 020) < 8 || (unsigned) (reg_renumber[REGNO] ^ 020) < 8) > +/* True for data registers, D0 through D7. */ > +#define DATA_REGNO_P(REGNO) ((unsigned int) (REGNO) < 8) > + > +/* True for address registers, A0 through A7. */ > +#define ADDRESS_REGNO_P(REGNO) (((unsigned int) (REGNO) - 8) < 8) > + > +/* True for integer registers, D0 through D7 and A0 through A7. */ > +#define INT_REGNO_P(REGNO) ((unsigned int) (REGNO) < 16) > + > +/* True for floating point registers, FP0 through FP7. */ > +#define FP_REGNO_P(REGNO) (((unsigned int) (REGNO) - 16) < 8) > + > +#define REGNO_OK_FOR_INDEX_P(REGNO) \ > + (INT_REGNO_P (REGNO) \ > + || INT_REGNO_P (reg_renumber[REGNO])) > + > +#define REGNO_OK_FOR_BASE_P(REGNO) \ > + (ADDRESS_REGNO_P (REGNO) \ > + || ADDRESS_REGNO_P (reg_renumber[REGNO])) > + > +#define REGNO_OK_FOR_DATA_P(REGNO) \ > + (DATA_REGNO_P (REGNO) \ > + || DATA_REGNO_P (reg_renumber[REGNO])) > + > +#define REGNO_OK_FOR_FP_P(REGNO) \ > + (FP_REGNO_P (REGNO) \ > + || FP_REGNO_P (reg_renumber[REGNO])) > > /* Now macros that check whether X is a register and also, > strictly, whether it is in a specified class. This is not directly related to the patch, but because I'm seeing it and I'm wondering about it. Other archs like i386 only have the ...__OK_FOR_INDEX_P/_OK_FOR_BASE_P variants and only there is reg_renumber is used. On m68k we also use it for the more general macros like DATA_REG_P/ADDRESS_REG_P. The question is, couldn't we cleanup the reg_renumber usage a little here? bye, Roman ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 20/63] Factor out soft-float library support 2007-01-10 11:17 ` [ColdFire 20/63] Factor out soft-float library support Richard Sandiford 2007-01-10 11:19 ` [ColdFire 21/63] Add *_REGNO_P macros Richard Sandiford @ 2007-01-10 21:32 ` Jeffrey Law 2007-01-10 21:51 ` Richard Sandiford 1 sibling, 1 reply; 280+ messages in thread From: Jeffrey Law @ 2007-01-10 21:32 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches On Wed, 2007-01-10 at 11:17 +0000, Richard Sandiford wrote: > The soft-float makefile fragments are duplicated in several target files. > This patch moves them to a common file called t-floatlib. It also > prevents the XFmode patterns from being used on ColdFire targets, > for which long double is now DFmode. > > Richard > > > gcc/ > 200x-xx-xx Nathan Sidwell <nathan@codesourcery.com> > > * config.gcc (m68k-*-aout*, m68k-*-coff*, m68020-*-elf*, m68k-*-elf*) > (m68k-*-uclinux*, m68k-*-rtems*): Add t-floatlib to $tmake_file. > * config/m68k/t-floatlib: New file, extracting common code from... > * config/m68k/t-m68kbare, config/m68k/t-m68kelf, > * config/m68k/t-uclinux: Here. > * config/m68k/fpgnulib.c: Do not compile extendeed precision > routines on ColdFire targets. Is there any way to make this work if the size of a long double is configurable? I'm not comfortable just changing the size of a long double -- I strongly suspet there's going to be some users who will want to continue to have the extended doubles. Assuming that's the case, then we can't simply assume that XFmode patterns aren't going to be used on coldfire, right? I'm certainly OK with moving the makefile fragments into a common file and just sucking that in rather than duplicating the fragment. jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 20/63] Factor out soft-float library support 2007-01-10 21:32 ` [ColdFire 20/63] Factor out soft-float library support Jeffrey Law @ 2007-01-10 21:51 ` Richard Sandiford 2007-01-10 22:08 ` Jeffrey Law 0 siblings, 1 reply; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 21:51 UTC (permalink / raw) To: law; +Cc: gcc-patches Jeffrey Law <law@redhat.com> writes: > On Wed, 2007-01-10 at 11:17 +0000, Richard Sandiford wrote: >> The soft-float makefile fragments are duplicated in several target files. >> This patch moves them to a common file called t-floatlib. It also >> prevents the XFmode patterns from being used on ColdFire targets, >> for which long double is now DFmode. >> >> Richard >> >> >> gcc/ >> 200x-xx-xx Nathan Sidwell <nathan@codesourcery.com> >> >> * config.gcc (m68k-*-aout*, m68k-*-coff*, m68020-*-elf*, m68k-*-elf*) >> (m68k-*-uclinux*, m68k-*-rtems*): Add t-floatlib to $tmake_file. >> * config/m68k/t-floatlib: New file, extracting common code from... >> * config/m68k/t-m68kbare, config/m68k/t-m68kelf, >> * config/m68k/t-uclinux: Here. >> * config/m68k/fpgnulib.c: Do not compile extendeed precision >> routines on ColdFire targets. > Is there any way to make this work if the size of a long double is > configurable? I'm not comfortable just changing the size of a > long double -- I strongly suspet there's going to be some users > who will want to continue to have the extended doubles. > > Assuming that's the case, then we can't simply assume that XFmode > patterns aren't going to be used on coldfire, right? Just so we're on the same page, the ColdFire FPU doesn't support extended precision. It's single and double precision only. Thus there aren't any XFmode patterns that could be used for ColdFire; everything would have to be handled with software emulation. As I said in my muddled reply earlier, I'm not aware that there actually is an XFmode emulation library for ColdFire, but like I say, that might be my ignorance. Richard ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 20/63] Factor out soft-float library support 2007-01-10 21:51 ` Richard Sandiford @ 2007-01-10 22:08 ` Jeffrey Law 0 siblings, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-01-10 22:08 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches On Wed, 2007-01-10 at 21:51 +0000, Richard Sandiford wrote: > Just so we're on the same page, the ColdFire FPU doesn't support > extended precision. It's single and double precision only. > Thus there aren't any XFmode patterns that could be used for > ColdFire; everything would have to be handled with software > emulation. > > As I said in my muddled reply earlier, I'm not aware that there > actually is an XFmode emulation library for ColdFire, but like > I say, that might be my ignorance. If there's never been a suitable XFmode library, then I think it should be OK to just document the change without any kind of backwards compat capabilities. jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 19/63] Make MOTOROLA a numeric macro from the outset 2007-01-10 11:16 ` [ColdFire 19/63] Make MOTOROLA a numeric macro from the outset Richard Sandiford 2007-01-10 11:17 ` [ColdFire 20/63] Factor out soft-float library support Richard Sandiford @ 2007-01-18 19:26 ` Richard Sandiford 1 sibling, 0 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-18 19:26 UTC (permalink / raw) To: gcc-patches Richard Sandiford <richard@codesourcery.com> writes: > Just a small cleanup. config/m68k wants MOTOROLA to be a numeric macro, > so this patch defines it that way from the outset. > > Richard > > > gcc/ > 200x-xx-xx Nathan Sidwell <nathan@codesourcery.com> > > * config.gcc (m68k-*-aout*, m68k-*-coff*, m68020-*-elf*, m68k-*-elf*) > (m68010-*-netbsdelf*, m68k*-*-netbsdelf*, m68k*-*-openbsd*) > (m68k-*-uclinux*, m68k-*-linux*, m68k-*-rtems*): Use tm_file rather > than m68k/m68k.h and explicitly set MOTOROLA to 1. > * config/m68k/m68k.h (MOTOROLA): Simplify definition accordingly. This is such a trivial cleanup that I went ahead and applied it as obvious. Richard ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 18/63] Configuration cleanups 2007-01-10 11:15 ` [ColdFire 18/63] Configuration cleanups Richard Sandiford 2007-01-10 11:16 ` [ColdFire 19/63] Make MOTOROLA a numeric macro from the outset Richard Sandiford @ 2007-01-10 18:51 ` Jeffrey Law 1 sibling, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-01-10 18:51 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches On Wed, 2007-01-10 at 11:15 +0000, Richard Sandiford wrote: > This patch just cleans up some of the configuration header files a little. > Specifically: > > - m68k.h defines PCC_STATIC_STRUCT_RETURN, but then every port except > openbsd undefines it again. It would be simpler to define > PCC_STATIC_STRUCT_RETURN in openbsd and remove the rest. > > It isn't clear whether the openbsd behaviour is intentional or not, > but I'd rather not change it as I have no way of testing it. > > - REGISTER_PREFIX_MD is never used. > > - m68k-none.h's CC1_SPEC is not needed because "" is the default. > > - m68020-elf.h's LIB_SPEC is not needed. The file is always included > after m68kemb.h, and its identical definition of LIB_SPEC still holds > when m68020-elf.h is included. > > - In the same way, m68k/linux.h's definition of SIZE_TYPE, > PTRDIFF_TYPE, WCHAR_TYPE and WCHAR_TYPE_SIZE are redundant > with the svr4.h definitions. Its TARGET_OBJFMT_CPP_BUILTINS > is redundant with the elfos.h definition. Its DBX_REGISTER_NUMBER > is redundant with the m68k.h definition. > > - The linux.h definition of TARGET_OS_CPP_BUILTINS includes some > mc680*0 macros. This code is redundant with TARGET_CPU_CPP_BUILTINS > and m68020 is not correct for ColdFire targets. > > - m68k-elf.h's and netbsd-elf's IMMEDIATE_PREFIX definitions are not > needed because "#" is the default. > > - m68k-elf.h's BSS_ASM_OP isn't needed because the macro is never used. > > - Likewise m68k-none's CPP_SUBTARGET_SPEC. > > - m68k-elf.h's NO_DOLLAR_IN_LABEL, ASM_OUTPUT_SKIP and ASM_OUTPUT_ASCII > are dead because elfos.h overrides them. (I can imagine that the > include order used to be the other way around, so I'm not sure how > intentional the current situation is. We haven't seen any problems > with it here though.) > > - Several files define ASM_OUTPUT_REG_PUSH and ASM_OUTPUT_REG_POP, > but these definitions are really just hard-coding a choice of > assembly dialect. We can make m68k.h define the macros for all > configurations and use MOTOROLA to choose the appropriate form. > > Richard > > > gcc/ > 200x-xx-xx Richard Sandiford <richard@codesourcery.com> > Nathan Sidwell <nathan@codesourcery.com> > > * config/m68k/m68k.h (PCC_STATIC_STRUCT_RETURN): Delete. > (ASM_OUTPUT_REG_PUSH, ASM_OUTPUT_REG_POP): Add MOTOROLA cases. > * config/m68k/coff.h (REGISTER_PREFIX_MD): Delete. > * config/m68k/m68020-elf.h (LIB_SPEC): Delete. > * config/m68k/m68k-none.h (CC1_SPEC, CPP_SUBTARGET_SPEC): Delete. > * config/m68k/m68kelf.h (IMMEDIATE_PREFIX, REGISTER_PREFIX_MD) > (ASM_OUTPUT_REG_PUSH, ASM_OUTPUT_REG_POP): Delete. > (NO_DOLLAR_IN_LABEL, PCC_STATIC_STRUCT_RETURN): Don't undefine. > (BSS_ASM_OP, ASM_OUTPUT_SKIP, ASM_OUTPUT_ASCII): Delete. > * config/m68k/m68kemb.h (PCC_STATIC_STRUCT_RETURN): Don't undefine. > * config/m68k/linux.h (SIZE_TYPE, PTRDIFF_TYPE, WCHAR_TYPE) > (WCHAR_TYPE_SIZE, TARGET_OBJFMT_CPP_BUILTINS): Delete. > (TARGET_OS_CPP_BUILTINS): Don't define mc68000 and mc68020 here. > (DBX_REGISTER_NUMBER): Delete. > * config/m68k/netbsd-elf.h (IMMEDIATE_PREFIX): Delete. > (PCC_STATIC_STRUCT_RETURN): Don't undefine. > * config/m68k/openbsd.h (PCC_STATIC_STRUCT_RETURN): Define. OK. Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 17/63] Assorted uClinux improvements 2007-01-10 11:13 ` [ColdFire 17/63] Assorted uClinux improvements Richard Sandiford 2007-01-10 11:15 ` [ColdFire 18/63] Configuration cleanups Richard Sandiford @ 2007-01-10 21:29 ` Jeffrey Law 2007-01-10 21:48 ` Richard Sandiford 1 sibling, 1 reply; 280+ messages in thread From: Jeffrey Law @ 2007-01-10 21:29 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches On Wed, 2007-01-10 at 11:13 +0000, Richard Sandiford wrote: > This patch makes several related changes to the uClinux supprt. It: > > - Converts the port to use .init and .fini sections. > > - Uses an .eh_frame section. Aren't these ABI changes as well? ie, if an end-user tried to mix and match objects compiled by different versions of GCC aren't they going to run into problems? If so, they need to be documented along with the other ABI changes we've noted. Otherwise it's OK as well. JEff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 17/63] Assorted uClinux improvements 2007-01-10 21:29 ` [ColdFire 17/63] Assorted uClinux improvements Jeffrey Law @ 2007-01-10 21:48 ` Richard Sandiford 0 siblings, 0 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 21:48 UTC (permalink / raw) To: law; +Cc: gcc-patches Jeffrey Law <law@redhat.com> writes: > On Wed, 2007-01-10 at 11:13 +0000, Richard Sandiford wrote: >> This patch makes several related changes to the uClinux supprt. It: >> >> - Converts the port to use .init and .fini sections. >> >> - Uses an .eh_frame section. > Aren't these ABI changes as well? Just to confirm that they are. > ie, if an end-user tried to mix and match objects compiled by > different versions of GCC aren't they going to run into problems? > If so, they need to be documented along with the other ABI changes > we've noted. OK. Richard ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 16/63] Bring *-uclinux configurations closer to *-linux-gnu 2007-01-10 11:10 ` [ColdFire 16/63] Bring *-uclinux configurations closer to *-linux-gnu Richard Sandiford 2007-01-10 11:13 ` [ColdFire 17/63] Assorted uClinux improvements Richard Sandiford @ 2007-01-10 19:21 ` Christoph Hellwig 2007-01-10 22:03 ` Richard Sandiford 2007-01-10 21:24 ` Jeffrey Law 2 siblings, 1 reply; 280+ messages in thread From: Christoph Hellwig @ 2007-01-10 19:21 UTC (permalink / raw) To: gcc-patches, richard On Wed, Jan 10, 2007 at 11:10:11AM +0000, Richard Sandiford wrote: > However, the current uClinux configuration is a form of *-elf rather > than *-linux-gnu. This leads to two important incompatibilities: > > - *-linux-gnu returns pointers in %a0 while *-uclinux returns then > in %d0. > > - *-linux-gnu uses %a1 as the incoming return address while > *-uclinux uses %a0. > > It seems odd to have this sort of difference. I would generally have > expected *-uclinux and *-linux* to have the same calling convention, > as the two are often source-compatible otherwise (even at the assembly > level). If we're making the major changes mentioned above anyway, and if > we're changing the ABI by redefining long double, it seems like a good > idea to remove this incompatibility too, and make *-linux-gnu and > *-uclinux variants of one another. > > This patch therefore makes *-uclinux include the linux headers and > makefiles, then override the uClinux-specific bits. > > As well as removing the incompabilities just mentioned, the patch > pulls in some useful things from the linux support. I don't think you can simply change the uclinux ABI. If you're going for this transition it needs to be done carefully, for example you should probably still support the old abi as -uclinux-oldabi targets as systems with the traditional ABI won't simply go away. The best place to discuss those issues is uclinux-dev@uclinux.org ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 16/63] Bring *-uclinux configurations closer to *-linux-gnu 2007-01-10 19:21 ` [ColdFire 16/63] Bring *-uclinux configurations closer to *-linux-gnu Christoph Hellwig @ 2007-01-10 22:03 ` Richard Sandiford 2007-01-10 22:13 ` Jeffrey Law 0 siblings, 1 reply; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 22:03 UTC (permalink / raw) To: Christoph Hellwig; +Cc: gcc-patches Christoph Hellwig <hch@infradead.org> writes: > On Wed, Jan 10, 2007 at 11:10:11AM +0000, Richard Sandiford wrote: >> However, the current uClinux configuration is a form of *-elf rather >> than *-linux-gnu. This leads to two important incompatibilities: >> >> - *-linux-gnu returns pointers in %a0 while *-uclinux returns then >> in %d0. >> >> - *-linux-gnu uses %a1 as the incoming return address while >> *-uclinux uses %a0. >> >> It seems odd to have this sort of difference. I would generally have >> expected *-uclinux and *-linux* to have the same calling convention, >> as the two are often source-compatible otherwise (even at the assembly >> level). If we're making the major changes mentioned above anyway, and if >> we're changing the ABI by redefining long double, it seems like a good >> idea to remove this incompatibility too, and make *-linux-gnu and >> *-uclinux variants of one another. >> >> This patch therefore makes *-uclinux include the linux headers and >> makefiles, then override the uClinux-specific bits. >> >> As well as removing the incompabilities just mentioned, the patch >> pulls in some useful things from the linux support. > > I don't think you can simply change the uclinux ABI. If you're going > for this transition it needs to be done carefully, for example you > should probably still support the old abi as -uclinux-oldabi targets > as systems with the traditional ABI won't simply go away. OK. Does that sound reasonable to you Jeff? Split off a copy of the current uclinux configuration as m68k-*-uclinux-oldabi? The copied uclinux.h could restore the original long double type too for maximum compatibility. If so, I'll prepare a patch. Richard ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 16/63] Bring *-uclinux configurations closer to *-linux-gnu 2007-01-10 22:03 ` Richard Sandiford @ 2007-01-10 22:13 ` Jeffrey Law 2007-01-12 12:08 ` Richard Sandiford 0 siblings, 1 reply; 280+ messages in thread From: Jeffrey Law @ 2007-01-10 22:13 UTC (permalink / raw) To: Richard Sandiford; +Cc: Christoph Hellwig, gcc-patches On Wed, 2007-01-10 at 22:03 +0000, Richard Sandiford wrote: > > > > I don't think you can simply change the uclinux ABI. If you're going > > for this transition it needs to be done carefully, for example you > > should probably still support the old abi as -uclinux-oldabi targets > > as systems with the traditional ABI won't simply go away. > > OK. Does that sound reasonable to you Jeff? Split off a copy > of the current uclinux configuration as m68k-*-uclinux-oldabi? > The copied uclinux.h could restore the original long double > type too for maximum compatibility. > > If so, I'll prepare a patch. It sounds quite reasonable to me. jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 16/63] Bring *-uclinux configurations closer to *-linux-gnu 2007-01-10 22:13 ` Jeffrey Law @ 2007-01-12 12:08 ` Richard Sandiford 2007-01-16 17:45 ` Jeffrey Law 0 siblings, 1 reply; 280+ messages in thread From: Richard Sandiford @ 2007-01-12 12:08 UTC (permalink / raw) To: law; +Cc: Christoph Hellwig, gcc-patches Jeffrey Law <law@redhat.com> writes: > On Wed, 2007-01-10 at 22:03 +0000, Richard Sandiford wrote: >> > >> > I don't think you can simply change the uclinux ABI. If you're going >> > for this transition it needs to be done carefully, for example you >> > should probably still support the old abi as -uclinux-oldabi targets >> > as systems with the traditional ABI won't simply go away. >> >> OK. Does that sound reasonable to you Jeff? Split off a copy >> of the current uclinux configuration as m68k-*-uclinux-oldabi? >> The copied uclinux.h could restore the original long double >> type too for maximum compatibility. >> >> If so, I'll prepare a patch. > It sounds quite reasonable to me. I eneded up calling it m68k-uclinuxoldabi as m68k-uclinux-oldabi would require config.sub changes. (This would be an issue for users too, if they're trying to use --host=m68k-uclinux-oldabi to configure some external package.) I spot-checked the new configuration by building gcc/ and checking that it was using the right headers. I don't have a way of really testing uclinux without the later ABI changes. OK to install? (The patch doesn't include the new uclinux-oldabi.h file because I'd create it using "svn cp".) Richard * doc/install.texi: Document m68k-uclinuxoldabi. * config.gcc (m68k-*-uclinuxoldabi): New configuration. * config/m68k/uclinux-oldabi.h: New file, copied from... * config/m68k/uclinux.h: ...here. Index: gcc/doc/install.texi =================================================================== --- gcc/doc/install.texi (revision 120718) +++ gcc/doc/install.texi (working copy) @@ -2397,6 +2397,8 @@ information are. @item @uref{#m68k-hp-hpux,,m68k-hp-hpux} @item +@uref{#m68k-uclinux,,m68k-uclinux} +@item @uref{#mips-x-x,,mips-*-*} @item @uref{#mips-sgi-irix5,,mips-sgi-irix5} @@ -3447,6 +3449,14 @@ to look like: #!/bin/ksh @end smallexample +@heading @anchor{m68k-x-uclinux}m68k-*-uclinux +GCC 4.3 changed the uClinux configuration so that it uses the +@samp{m68k-linux-gnu} ABI rather than the @samp{m68k-elf} ABI. +It also added improved support for C++ and flat shared libraries, +both of which were ABI changes. However, you can still use the +original ABI by configuring for @samp{m68k-uclinuxoldabi} or +@samp{m68k-@var{vendor}-uclinuxoldabi}. + @html <hr /> @end html Index: gcc/config.gcc =================================================================== --- gcc/config.gcc (revision 120713) +++ gcc/config.gcc (working copy) @@ -1510,7 +1510,18 @@ m68k*-*-openbsd*) # we need collect2 until our bug is fixed... use_collect2=yes ;; -m68k-*-uclinux*) # Motorola m68k/ColdFire running uClinux with uClibc +m68k-*-uclinuxoldabi*) # Motorola m68k/ColdFire running uClinux + # with uClibc, using the original + # m68k-elf-based ABI + default_m68k_cpu=68020 + tm_file="m68k/m68k.h m68k/m68k-none.h m68k/m68kelf.h dbxelf.h elfos.h m68k/uclinux-oldabi.h" + tm_defines="${tm_defines} MOTOROLA USE_GAS" + tmake_file=m68k/t-uclinux + use_fixproto=no + ;; +m68k-*-uclinux*) # Motorola m68k/ColdFire running uClinux + # with uClibc, using the new GNU/Linux-style + # ABI. default_m68k_cpu=68020 tm_file="m68k/m68k.h m68k/m68k-none.h m68k/m68kelf.h dbxelf.h elfos.h m68k/uclinux.h" tm_defines="${tm_defines} MOTOROLA USE_GAS" ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 16/63] Bring *-uclinux configurations closer to *-linux-gnu 2007-01-12 12:08 ` Richard Sandiford @ 2007-01-16 17:45 ` Jeffrey Law 0 siblings, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-01-16 17:45 UTC (permalink / raw) To: Richard Sandiford; +Cc: Christoph Hellwig, gcc-patches On Fri, 2007-01-12 at 12:08 +0000, Richard Sandiford wrote: > Jeffrey Law <law@redhat.com> writes: > > On Wed, 2007-01-10 at 22:03 +0000, Richard Sandiford wrote: > >> > > >> > I don't think you can simply change the uclinux ABI. If you're going > >> > for this transition it needs to be done carefully, for example you > >> > should probably still support the old abi as -uclinux-oldabi targets > >> > as systems with the traditional ABI won't simply go away. > >> > >> OK. Does that sound reasonable to you Jeff? Split off a copy > >> of the current uclinux configuration as m68k-*-uclinux-oldabi? > >> The copied uclinux.h could restore the original long double > >> type too for maximum compatibility. > >> > >> If so, I'll prepare a patch. > > It sounds quite reasonable to me. > > I eneded up calling it m68k-uclinuxoldabi as m68k-uclinux-oldabi > would require config.sub changes. (This would be an issue for > users too, if they're trying to use --host=m68k-uclinux-oldabi > to configure some external package.) > > I spot-checked the new configuration by building gcc/ and > checking that it was using the right headers. I don't have > a way of really testing uclinux without the later ABI changes. > > OK to install? > > (The patch doesn't include the new uclinux-oldabi.h file because > I'd create it using "svn cp".) > > Richard > > > * doc/install.texi: Document m68k-uclinuxoldabi. > * config.gcc (m68k-*-uclinuxoldabi): New configuration. > * config/m68k/uclinux-oldabi.h: New file, copied from... > * config/m68k/uclinux.h: ...here. Looks reasonable to me. Thanks, Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 16/63] Bring *-uclinux configurations closer to *-linux-gnu 2007-01-10 11:10 ` [ColdFire 16/63] Bring *-uclinux configurations closer to *-linux-gnu Richard Sandiford 2007-01-10 11:13 ` [ColdFire 17/63] Assorted uClinux improvements Richard Sandiford 2007-01-10 19:21 ` [ColdFire 16/63] Bring *-uclinux configurations closer to *-linux-gnu Christoph Hellwig @ 2007-01-10 21:24 ` Jeffrey Law 2 siblings, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-01-10 21:24 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches On Wed, 2007-01-10 at 11:10 +0000, Richard Sandiford wrote: > The next patch in the series will make some major changes to the > uClinux support. The idea is to make it seem more like a full > ELF (GNU or non-GNU) linux target. > > However, the current uClinux configuration is a form of *-elf rather > than *-linux-gnu. This leads to two important incompatibilities: > > - *-linux-gnu returns pointers in %a0 while *-uclinux returns then > in %d0. > > - *-linux-gnu uses %a1 as the incoming return address while > *-uclinux uses %a0. > > It seems odd to have this sort of difference. I would generally have > expected *-uclinux and *-linux* to have the same calling convention, > as the two are often source-compatible otherwise (even at the assembly > level). If we're making the major changes mentioned above anyway, and if > we're changing the ABI by redefining long double, it seems like a good > idea to remove this incompatibility too, and make *-linux-gnu and > *-uclinux variants of one another. > > This patch therefore makes *-uclinux include the linux headers and > makefiles, then override the uClinux-specific bits. > > As well as removing the incompabilities just mentioned, the patch > pulls in some useful things from the linux support. For example, > the linux trampoline code uses a cacheflush syscall, whereas the > current uClinux configuration is not cache-friendly. > > Richard > > > gcc/ > * config.gcc (m68k-*-uclinux*): Base the port on the common > and m68k GNU/Linux files rather than on the generic ELF ones. > * config/m68k/uclinux.h (TARGET_VERSION): Override. > (TARGET_OS_CPP_BUILTINS): Use LINUX_TARGET_OS_CPP_BUILTINS. I'm OK with this as long as we document this ABI change as well so that uclinux users aren't caught off guard. jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 15/63] Avoid out-of-segment constants on uClinux. 2007-01-10 11:05 ` [RTL, ColdFire 15/63] Avoid out-of-segment constants on uClinux Richard Sandiford 2007-01-10 11:10 ` [ColdFire 16/63] Bring *-uclinux configurations closer to *-linux-gnu Richard Sandiford @ 2007-01-11 4:53 ` Roger Sayle 2007-01-11 17:16 ` Jeffrey Law 2007-01-11 17:15 ` Jeffrey Law 2 siblings, 1 reply; 280+ messages in thread From: Roger Sayle @ 2007-01-11 4:53 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches Hi Richard, On Wed, 10 Jan 2007, Richard Sandiford wrote: > > gcc/ > * Makefile.in (rtlanal.o): Depend on tree.h. > * rtl.h (offset_within_section_p, split_const): Declare. > * rtlanal.c: Include tree.h. > (offset_within_block_p): New function, taken from > mips_offset_within_object_p. > (split_const): New function, taken from mips_split_const. The middle-end infrastructure bits of this patch are OK for mainline. The relevant functions look reasonable to share in the rtlanal.c rather than duplicate in each backend. Roger -- ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 15/63] Avoid out-of-segment constants on uClinux. 2007-01-11 4:53 ` [RTL, ColdFire 15/63] Avoid out-of-segment constants on uClinux Roger Sayle @ 2007-01-11 17:16 ` Jeffrey Law 0 siblings, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-01-11 17:16 UTC (permalink / raw) To: Roger Sayle; +Cc: Richard Sandiford, gcc-patches On Wed, 2007-01-10 at 21:47 -0700, Roger Sayle wrote: > Hi Richard, > > On Wed, 10 Jan 2007, Richard Sandiford wrote: > > > > gcc/ > > * Makefile.in (rtlanal.o): Depend on tree.h. > > * rtl.h (offset_within_section_p, split_const): Declare. > > * rtlanal.c: Include tree.h. > > (offset_within_block_p): New function, taken from > > mips_offset_within_object_p. > > (split_const): New function, taken from mips_split_const. > > The middle-end infrastructure bits of this patch are OK for mainline. > The relevant functions look reasonable to share in the rtlanal.c > rather than duplicate in each backend. Agreed. There may be other ports that can use this infrastructure as well. The mn103 has some similar segmentation issues as does the PA. Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [RTL, ColdFire 15/63] Avoid out-of-segment constants on uClinux. 2007-01-10 11:05 ` [RTL, ColdFire 15/63] Avoid out-of-segment constants on uClinux Richard Sandiford 2007-01-10 11:10 ` [ColdFire 16/63] Bring *-uclinux configurations closer to *-linux-gnu Richard Sandiford 2007-01-11 4:53 ` [RTL, ColdFire 15/63] Avoid out-of-segment constants on uClinux Roger Sayle @ 2007-01-11 17:15 ` Jeffrey Law 2 siblings, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-01-11 17:15 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches On Wed, 2007-01-10 at 11:05 +0000, Richard Sandiford wrote: > One of the big problems with the uClinux flat format is that it cannot > cope with relocations that point outside the symbol's containing segment. > E.g. things like: > > extern unsigned char a[]; > ... &a[12345 - x] ... > > cannot be implemented as "&a[12345] - x" because "a" might be less than > 12345 bytes from the end of the segment. This problem applies to both > text and data relocations: we should never emit a symbolic constant > if we are unsure whether it is contained within the symbol's segment. > > MIPS has a similar problem for other reasons, so this patch moves two > helper routines, mips_offset_within_block_p and mips_split_const, > from mips.c to rtlanal.c (removing the mips_ prefixes, of course). > > The patch also removes the unused predicates from the movsi expander. > It seems odd to handle non-legitimate operands in something that appears > to be (but really isn't) guarded by *_operand predicates. > > One problem with this patch is that we sometimes need to access > individual bytes or words of wider MEMs. This will ICE if the > wider MEM has a legitimate constant address but the narrower > one doesn't. This is a generic problem that applies to all > addresses with limited ranges, and a later patch will fix it. > > FWIW, bfin_legitimate_constant_p does something similar, but it > doesn't cope with constant pool entries or object blocks, neither > of which the Blackfin port uses. > > The split_const function is similar to get_related_value and > get_integer_term, but has the advantage of (a) only walking the > rtl once and (b) returning an rtx offset, so that if the caller > needs an rtx, it doesn't need to regenerate one from the HOST_WIDE_INT. > (get_related_value and get_integer_term also cope with MINUS of a > CONST_INT, but that isn't canonical rtl.) > > Boostrapped & regression-tested on x86_64-linux-gnu. I also compared > the assembly output of mipsisa64-elf and mips64-linux-gnu for the > C and C++ testsuites, using the options: > > -O0 > -O2 > -mabi=n32 > -mabi=64 > -mabi=eabi -mno-abicalls > -mabi=32 > -mabi=o64 > > There were no differences. I'll sign off on the MIPS bits if > everything else is OK. > > Richard > > > gcc/ > * Makefile.in (rtlanal.o): Depend on tree.h. > * rtl.h (offset_within_section_p, split_const): Declare. > * rtlanal.c: Include tree.h. > (offset_within_block_p): New function, taken from > mips_offset_within_object_p. > (split_const): New function, taken from mips_split_const. > * config/m68k/m68k-protos.h (m68k_illegitimate_symbolic_constant_p): > Declare. > * config/m68k/m68k.h (M68K_OFFSETS_MUST_BE_WITHIN_SECTIONS_P): Define. > (CONSTANT_ADDRESS_P): Only accept legitimate constants. > (LEGITIMATE_CONSTANT_P): Check m68k_illegitimate_symbolic_constant_p. > * config/m68k/m68k.c (TARGET_CANNOT_FORCE_CONST_MEM): Define. > (m68k_illegitimate_symbolic_constant_p): New function. > * config/m68k/m68k.md (movsi): Remove misleading predicates. > If M68K_OFFSETS_MUST_BE_WITHIN_SECTIONS_P and the source is a > symbolic constant that might be outside the symbol's section, > move the symbol first and then add the offset. > * config/m68k/uclinux.h (M68K_OFFSETS_MUST_BE_WITHIN_SECTIONS_P): > Override. > * config/mips/mips.c (mips_split_const): Delete. > (mips_offset_within_object_p): Delete. > (mips_symbolic_constant_p): Use offset_within_section_p and > split_const instead of mips_offset_within_object_p and > mips_split_const. > (mips_cannot_force_const_mem, mips_const_insns, mips_unspec_address) > (mips_legitimize_const_move, print_operand_reloc) > (mips_dangerous_for_la25_p): Use split_const instead of > mips_split_const. OK. THanks. Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 14/63] Make "long double" the same as "double" on ColdFire 2007-01-10 11:02 ` [ColdFire 14/63] Make "long double" the same as "double" on ColdFire Richard Sandiford 2007-01-10 11:05 ` [RTL, ColdFire 15/63] Avoid out-of-segment constants on uClinux Richard Sandiford @ 2007-01-10 18:35 ` Jeffrey Law 2007-01-11 10:51 ` Nathan Sidwell 1 sibling, 1 reply; 280+ messages in thread From: Jeffrey Law @ 2007-01-10 18:35 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches On Wed, 2007-01-10 at 11:01 +0000, Richard Sandiford wrote: > When we (CodeSourcery) polled ColdFire folks, there seemed to be > general agreement that "long double" should be the same as "double" > on ColdFire. There doesn't seem much point emulating the m68k > XFmode format. > > This patch adjusts LONG_DOUBLE_TYPE_SIZE accordingly. It's an ABI > change for all ColdFire targets. > > Richard > > > gcc/ > 200x-xx-xx Julian Brown <julian@codesourcery.com> > > * config/m68k/m68k.h (LONG_DOUBLE_TYPE_SIZE): Make 64-bit on ColdFire. > (LIBGCC2_LONG_DOUBLE_TYPE_SIZE): Likewise. > * config/m68k/netbsd-elf.h (LIBGCC2_LONG_DOUBLE_TYPE_SIZE): Undefine > before redefining. Where/how do we document ABI changes for releases? Even if the coldfire users are in agreement we need a reasonable way to notify them when the ABI has changed. It also seems to me that if this can be configurable, then it probably should be given that we're changing the current behavior. Even if you've polled many coldfire users, there's a reasonable chance there's someone out there you missed that's using 128bit long doubles. Let's table this one temporarily. jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 14/63] Make "long double" the same as "double" on ColdFire 2007-01-10 18:35 ` [ColdFire 14/63] Make "long double" the same as "double" on ColdFire Jeffrey Law @ 2007-01-11 10:51 ` Nathan Sidwell 2007-01-11 17:20 ` Jeffrey Law 0 siblings, 1 reply; 280+ messages in thread From: Nathan Sidwell @ 2007-01-11 10:51 UTC (permalink / raw) To: law; +Cc: Richard Sandiford, gcc-patches Jeffrey Law wrote: >> 200x-xx-xx Julian Brown <julian@codesourcery.com> >> >> * config/m68k/m68k.h (LONG_DOUBLE_TYPE_SIZE): Make 64-bit on ColdFire. >> (LIBGCC2_LONG_DOUBLE_TYPE_SIZE): Likewise. >> * config/m68k/netbsd-elf.h (LIBGCC2_LONG_DOUBLE_TYPE_SIZE): Undefine >> before redefining. > Where/how do we document ABI changes for releases? Even if the coldfire > users are in agreement we need a reasonable way to notify them when the > ABI has changed. > > It also seems to me that if this can be configurable, then it probably > should be given that we're changing the current behavior. Even if > you've polled many coldfire users, there's a reasonable chance there's > someone out there you missed that's using 128bit long doubles. > > Let's table this one temporarily. Jeffrey Law also wrote: > On Wed, 2007-01-10 at 21:51 +0000, Richard Sandiford wrote: > >> Just so we're on the same page, the ColdFire FPU doesn't support >> extended precision. It's single and double precision only. >> Thus there aren't any XFmode patterns that could be used for >> ColdFire; everything would have to be handled with software >> emulation. >> >> As I said in my muddled reply earlier, I'm not aware that there >> actually is an XFmode emulation library for ColdFire, but like >> I say, that might be my ignorance. > If there's never been a suitable XFmode library, then I think it > should be OK to just document the change without any kind of > backwards compat capabilities. Just so we're all on the same page, do you still want the long double change held back -- just so you know, 'to table' has opposite meanings in American and British English, I'm guessing you're using the American meaning :) The original, rather short, thread discussing the long double change is http://gcc.gnu.org/ml/gcc/2005-12/msg00221.html. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan@codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 14/63] Make "long double" the same as "double" on ColdFire 2007-01-11 10:51 ` Nathan Sidwell @ 2007-01-11 17:20 ` Jeffrey Law 2007-01-18 18:46 ` Richard Sandiford 0 siblings, 1 reply; 280+ messages in thread From: Jeffrey Law @ 2007-01-11 17:20 UTC (permalink / raw) To: Nathan Sidwell; +Cc: Richard Sandiford, gcc-patches On Thu, 2007-01-11 at 10:51 +0000, Nathan Sidwell wrote: > Just so we're all on the same page, do you still want the long double change > held back -- just so you know, 'to table' has opposite meanings in American and > British English, I'm guessing you're using the American meaning :) > > The original, rather short, thread discussing the long double change is > http://gcc.gnu.org/ml/gcc/2005-12/msg00221.html. No need to hold it back if there's never been an XFmode emulation library for the coldfire. Though we should still document the ABI change. Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 14/63] Make "long double" the same as "double" on ColdFire 2007-01-11 17:20 ` Jeffrey Law @ 2007-01-18 18:46 ` Richard Sandiford 0 siblings, 0 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-18 18:46 UTC (permalink / raw) To: law; +Cc: Nathan Sidwell, gcc-patches Jeffrey Law <law@redhat.com> writes: > On Thu, 2007-01-11 at 10:51 +0000, Nathan Sidwell wrote: > >> Just so we're all on the same page, do you still want the long double change >> held back -- just so you know, 'to table' has opposite meanings in American and >> British English, I'm guessing you're using the American meaning :) >> >> The original, rather short, thread discussing the long double change is >> http://gcc.gnu.org/ml/gcc/2005-12/msg00221.html. > No need to hold it back if there's never been an XFmode emulation > library for the coldfire. Though we should still document the > ABI change. Thanks. For the record, here's the patch I applied. It restores the 80-bit long double for the new uclinuxoldabi configuration, but it's otherwise unchanged. I've queued the changes.html text until the entire patch series is in; I'll post a single documentation patch then. Richard gcc/ 200x-xx-xx Julian Brown <julian@codesourcery.com> Richard Sandiford <richard@codesourcery.com> * config/m68k/m68k.h (LONG_DOUBLE_TYPE_SIZE): Make 64-bit on ColdFire. (LIBGCC2_LONG_DOUBLE_TYPE_SIZE): Likewise. * config/m68k/netbsd-elf.h (LIBGCC2_LONG_DOUBLE_TYPE_SIZE): Undefine before redefining. * config/m68k/uclinux-oldabi.h (LONG_DOUBLE_TYPE_SIZE): Redefine to 80 unconditionally. (LIBGCC2_LONG_DOUBLE_TYPE_SIZE): Likewise. Index: gcc/config/m68k/m68k.h =================================================================== --- gcc/config/m68k/m68k.h 2007-01-09 15:01:54.000000000 +0000 +++ gcc/config/m68k/m68k.h 2007-01-09 15:01:56.000000000 +0000 @@ -259,7 +259,17 @@ #define SUBTARGET_OVERRIDE_OPTIONS \f /* target machine storage layout */ -#define LONG_DOUBLE_TYPE_SIZE 80 +/* "long double" is the same as "double" on ColdFire targets. */ + +#define LONG_DOUBLE_TYPE_SIZE (TARGET_COLDFIRE ? 64 : 80) + +/* We need to know the size of long double at compile-time in libgcc2. */ + +#ifdef __mcoldfire__ +#define LIBGCC2_LONG_DOUBLE_TYPE_SIZE 64 +#else +#define LIBGCC2_LONG_DOUBLE_TYPE_SIZE 80 +#endif /* Set the value of FLT_EVAL_METHOD in float.h. When using 68040 fp instructions, we get proper intermediate rounding, otherwise we Index: gcc/config/m68k/netbsd-elf.h =================================================================== --- gcc/config/m68k/netbsd-elf.h 2007-01-09 15:01:51.000000000 +0000 +++ gcc/config/m68k/netbsd-elf.h 2007-01-09 15:01:56.000000000 +0000 @@ -40,6 +40,7 @@ #define TARGET_OS_CPP_BUILTINS() \ #undef LONG_DOUBLE_TYPE_SIZE #define LONG_DOUBLE_TYPE_SIZE (TARGET_68020 ? 80 : 64) +#undef LIBGCC2_LONG_DOUBLE_TYPE_SIZE #ifdef __mc68010__ #define LIBGCC2_LONG_DOUBLE_TYPE_SIZE 64 #else Index: gcc/config/m68k/uclinux-oldabi.h =================================================================== --- gcc/config/m68k/uclinux-oldabi.h (revision 120909) +++ gcc/config/m68k/uclinux-oldabi.h (working copy) @@ -22,6 +22,12 @@ the Free Software Foundation; either ver Boston, MA 02110-1301, USA. */ +/* The old uClinux ABI used 80-byte "long double"s for ColdFire too. */ +#undef LONG_DOUBLE_TYPE_SIZE +#define LONG_DOUBLE_TYPE_SIZE 80 +#undef LIBGCC2_LONG_DOUBLE_TYPE_SIZE +#define LIBGCC2_LONG_DOUBLE_TYPE_SIZE 80 + /* Undo the definition of STARTFILE_SPEC from m68kelf.h so we'll pick the default from gcc.c (just link crt0.o from multilib dir). */ #undef STARTFILE_SPEC ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 13/63] Remove some RejectNegatives 2007-01-10 11:00 ` [ColdFire 13/63] Remove some RejectNegatives Richard Sandiford 2007-01-10 11:02 ` [ColdFire 14/63] Make "long double" the same as "double" on ColdFire Richard Sandiford @ 2007-01-10 18:32 ` Jeffrey Law 1 sibling, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-01-10 18:32 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches On Wed, 2007-01-10 at 11:00 +0000, Richard Sandiford wrote: > Some of the boolean m68k options have no negative counterpart. > There seems to be no specific reason for this, as the negatives > would work, so this patch adds them. -mno-bitfield is now a > (more canonical) synonym for -mnobitfield. > > (I suppose that before the .opt transition, it was more effort to add > boolean options with negative counterparts, whereas the opposite is > now true. As before, I'd tried to preserve existing practice when > converting the m68k port.) > > The patch also resorts m68k.opt into alphabetical order. > > Richard > > > gcc/ > 200x-xx-xx Nathan Sidwell <nathan@codesourcery.com> > Richard Sandiford <richard@codesourcery.com> > > * doc/invoke.texi: Document -mno-bitfield, -mno-rtd and -mno-short. > * config/m68k/m68k.opt: Resort options. > (mbitfield, mrtd, mshort): Remove RejectNegative properties. OK. Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 12/63] Add new predefined macros 2007-01-10 10:58 ` [ColdFire 12/63] Add new predefined macros Richard Sandiford 2007-01-10 11:00 ` [ColdFire 13/63] Remove some RejectNegatives Richard Sandiford @ 2007-01-10 18:31 ` Jeffrey Law 1 sibling, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-01-10 18:31 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches On Wed, 2007-01-10 at 10:58 +0000, Richard Sandiford wrote: > This patch adds some new cpp macros. Specifically: > > - it adds __mcfv[2345]__ macros, to go alongside the existing __mcfv4e__. > > - it defines __mcffpu__ when the ColdFire FPU is enabled > > - it defines __mcf_cpu_CPU and __mcf_family_FAMILY when a ColdFire CPU > is selected. (These macros are used in the libgloss crt code.) > > The patch also documents some existing macros in invoke.texi. > > Richard > > > gcc/ > 200x-xx-xx Nathan Sidwell <nathan@codesourcery.com> > Richard Sandiford <richard@codesourcery.com> > > * doc/invoke.texi: Document the macros that are defined by > m68k's -mtune and -mhard-float options. > * config/m68k/m68k-protos.h (m68k_cpp_cpu_ident) Declare. > (m68k_cpp_cpu_family): Likewise. > * config/m68k/m68k.h (TARGET_CPU_CPP_BUILTINS): Add a full set > of __ucfv*__ macros. Define __mcffpu__ if generating code for > ColdFire FPUs. Define __mcf_cpu_* and __mcf_family_* macros. > * config/m68k/m68k.c (m68k_cpp_cpu_ident): New function. > (m68k_cpp_cpu_family): Likewise. OK. Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 11/63] Treat mc680x0 macros as tuning-dependent macros 2007-01-10 10:57 ` [ColdFire 11/63] Treat mc680x0 macros as tuning-dependent macros Richard Sandiford 2007-01-10 10:58 ` [ColdFire 12/63] Add new predefined macros Richard Sandiford @ 2007-01-10 18:28 ` Jeffrey Law 1 sibling, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-01-10 18:28 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches On Wed, 2007-01-10 at 10:57 +0000, Richard Sandiford wrote: > The mc680[12346]0 macros are effectively tuning macros. E.g. -m68020-40 > sets mc68020, mc68030 and mc68040, even though it only generates mc68020 > instructions. This patch makes that more explicit by setting the macros > in an m68k_tune switch statement. The next patch will add ColdFire > macros to it. > > Richard > > > gcc/ > * config/m68k/m68k.h (TARGET_CPU_CPP_BUILTINS): Treat all mc68* > macros besides mc68000 as tuning macros. Use a switch statement > to set them and mcpu32. OK. Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 10/63] Rename TARGET_68040_ONLY to TARGET_68040 2007-01-10 10:55 ` [ColdFire 10/63] Rename TARGET_68040_ONLY to TARGET_68040 Richard Sandiford 2007-01-10 10:57 ` [ColdFire 11/63] Treat mc680x0 macros as tuning-dependent macros Richard Sandiford @ 2007-01-10 18:27 ` Jeffrey Law 1 sibling, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-01-10 18:27 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches On Wed, 2007-01-10 at 10:55 +0000, Richard Sandiford wrote: > At this point in the series, we've got rid of the architecture MASK_*s > and added TUNE_* macros. TARGET_68040_ONLY can now be called TARGET_68040, > for consistency with the other ISA macros. > > Richard > > > gcc/ > 200x-xx-xx Julian Brown <julian@codesourcery.com> > > * config/m68k/m68k.h: Use TARGET_68040 instead of TARGET_68040_ONLY. > (TARGET_68040_ONLY): Rename to... > (TARGET_68040): ...this. > * config/m68k/m68k.c: Use TARGET_68040 instead of TARGET_68040_ONLY. > * config/m68k/m68k.md: Likewise. OK. Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 9/63] Add -mcpu, -march, -mtune, and related options 2007-01-10 10:54 ` [ColdFire 9/63] Add -mcpu, -march, -mtune, and related options Richard Sandiford 2007-01-10 10:55 ` [ColdFire 10/63] Rename TARGET_68040_ONLY to TARGET_68040 Richard Sandiford @ 2007-01-10 18:22 ` Jeffrey Law 2007-01-15 18:08 ` Roman Zippel 2007-04-12 1:53 ` Roman Zippel 3 siblings, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-01-10 18:22 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches On Wed, 2007-01-10 at 10:54 +0000, Richard Sandiford wrote: > An obvious implication is that -m68020 should be orthogonal to the > FPU selection, but the other architecture options shouldn't be. > However, I don't that's necessarily the reason why the code is > the way it is, because... I have no idea why it was done that way. It's never been terribly rational, though the irrationality is easier to see with the removal of the FPA support a few years ago. > > The m68k-* configurations all default to hard-float 68020, and if > you pass -m68020 to the m68k-* gccs, you still get hard-float code. > The only configuration for which the special treatment of -m68020 makes > a difference _in isolation_ is m68010-*-netbsdelf, which continues to > generate soft-float code when passed -m68020. However, I doubt that > the netbsd effect was a deliberate decision. It seems more logical > for "m68010-*-netbsdelf-gcc -m68020" to generate the same code as > m68k-*-netbsdelf-gcc, which is the equivalent 68020 configuration, > and which defaults to hard-float code. Agreed (it probably wasn't a deliberate decision). Particularly if they used my ancient 68010 HPBSD support as a template for netbsdelf (netbsdelf is a descendent of the HPBSD code on numerous levels). Jeff ps. I'm just going to blindly trust that you've got all the ColdFire variants right -- you're *far* more familiar with them than I am. ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 9/63] Add -mcpu, -march, -mtune, and related options 2007-01-10 10:54 ` [ColdFire 9/63] Add -mcpu, -march, -mtune, and related options Richard Sandiford 2007-01-10 10:55 ` [ColdFire 10/63] Rename TARGET_68040_ONLY to TARGET_68040 Richard Sandiford 2007-01-10 18:22 ` [ColdFire 9/63] Add -mcpu, -march, -mtune, and related options Jeffrey Law @ 2007-01-15 18:08 ` Roman Zippel 2007-01-15 22:40 ` Richard Sandiford 2007-04-12 1:53 ` Roman Zippel 3 siblings, 1 reply; 280+ messages in thread From: Roman Zippel @ 2007-01-15 18:08 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches Hi, On Wed, 10 Jan 2007, Richard Sandiford wrote: > The patch therefore stops m68k_handle_option from changing the float > setting and instead makes OVERRIDE_OPTIONS use the chosen architecture > to pick a default if none of -mhard-float, -m68881 and -msoft-float > are given. The default for 68020 is -mhard-float, to match the > existing defaults. The patch takes the same sort of approach for > -mbitfield and -mdiv too. While I agree that the cpu options shouldn't change the fpu option, I'm not sure about the default setting. The important point is that the 68881 switch also changes the ABI (the fp return value), so I think it might be better to leave the default to the target configuration. bye, Roman ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 9/63] Add -mcpu, -march, -mtune, and related options 2007-01-15 18:08 ` Roman Zippel @ 2007-01-15 22:40 ` Richard Sandiford 2007-01-16 2:43 ` Roman Zippel 0 siblings, 1 reply; 280+ messages in thread From: Richard Sandiford @ 2007-01-15 22:40 UTC (permalink / raw) To: Roman Zippel; +Cc: gcc-patches Roman Zippel <zippel@linux-m68k.org> writes: > On Wed, 10 Jan 2007, Richard Sandiford wrote: >> The patch therefore stops m68k_handle_option from changing the float >> setting and instead makes OVERRIDE_OPTIONS use the chosen architecture >> to pick a default if none of -mhard-float, -m68881 and -msoft-float >> are given. The default for 68020 is -mhard-float, to match the >> existing defaults. The patch takes the same sort of approach for >> -mbitfield and -mdiv too. > > While I agree that the cpu options shouldn't change the fpu option, I'm > not sure about the default setting. The important point is that the 68881 > switch also changes the ABI (the fp return value), so I think it might be > better to leave the default to the target configuration. I take your point, but AIUI, this just applies to 680x0 GNU/Linux and NetBSD. TARGET_COLDFIRE_FPU doesn't affect the calling conventions, and other targets return everything in %d0. So I think the only concrete example of where this would make a difference for a standard configuration (i.e. without arguments like --with-cpu) is m68010-netbsdelf. Like I said in the covering message, I think there's an argument that m68010-netbsdelf -m68020 should generate the same code as m68k-netbsdelf, which is the associated 68020 configuration. (I don't see any point in downgrading to pre-68020 on m68k-netbsdelf or m68k-linux-gnu.) I'm just hand-waving though. You know what's appropriate for 680x0 better than I do, so if you think they should be treated differently from ColdFire, I can take the default float setting for 680x0 targets from the float setting for the default CPU, rather than the chosen CPU. Richard ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 9/63] Add -mcpu, -march, -mtune, and related options 2007-01-15 22:40 ` Richard Sandiford @ 2007-01-16 2:43 ` Roman Zippel 2007-01-16 5:24 ` Richard Sandiford 0 siblings, 1 reply; 280+ messages in thread From: Roman Zippel @ 2007-01-16 2:43 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches Hi, On Mon, 15 Jan 2007, Richard Sandiford wrote: > I'm just hand-waving though. You know what's appropriate for 680x0 > better than I do, so if you think they should be treated differently > from ColdFire, I can take the default float setting for 680x0 targets > from the float setting for the default CPU, rather than the chosen CPU. For Linux it doesn't really matter, what I have in mind is that a generic target like m68k-elf could be used with --with-float=soft. bye, Roman ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 9/63] Add -mcpu, -march, -mtune, and related options 2007-01-16 2:43 ` Roman Zippel @ 2007-01-16 5:24 ` Richard Sandiford 2007-01-16 5:38 ` Richard Sandiford 0 siblings, 1 reply; 280+ messages in thread From: Richard Sandiford @ 2007-01-16 5:24 UTC (permalink / raw) To: Roman Zippel; +Cc: gcc-patches Roman Zippel <zippel@linux-m68k.org> writes: >> I'm just hand-waving though. You know what's appropriate for 680x0 >> better than I do, so if you think they should be treated differently >> from ColdFire, I can take the default float setting for 680x0 targets >> from the float setting for the default CPU, rather than the chosen CPU. > > For Linux it doesn't really matter, what I have in mind is that a generic > target like m68k-elf could be used with --with-float=soft. But what precisely do you think the semantics should be? Like I say, I think it's reasonable to use the device defaults for ColdFire, as -mhard-float does not change the calling conventions. Are you saying that you disagree, and that you think the default should be decided by the configuration regardless of -mcpu? Or are you saying that the default should be decided in a different way for 680x0 and ColdFire targets? Richard ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 9/63] Add -mcpu, -march, -mtune, and related options 2007-01-16 5:24 ` Richard Sandiford @ 2007-01-16 5:38 ` Richard Sandiford 2007-01-22 17:12 ` Roman Zippel 0 siblings, 1 reply; 280+ messages in thread From: Richard Sandiford @ 2007-01-16 5:38 UTC (permalink / raw) To: Roman Zippel; +Cc: gcc-patches Richard Sandiford <richard@codesourcery.com> writes: > Roman Zippel <zippel@linux-m68k.org> writes: >>> I'm just hand-waving though. You know what's appropriate for 680x0 >>> better than I do, so if you think they should be treated differently >>> from ColdFire, I can take the default float setting for 680x0 targets >>> from the float setting for the default CPU, rather than the chosen CPU. >> >> For Linux it doesn't really matter, what I have in mind is that a generic >> target like m68k-elf could be used with --with-float=soft. > > But what precisely do you think the semantics should be? > Like I say, I think it's reasonable to use the device defaults > for ColdFire, as -mhard-float does not change the calling conventions. > Are you saying that you disagree, and that you think the default should > be decided by the configuration regardless of -mcpu? Or are you saying > that the default should be decided in a different way for 680x0 and > ColdFire targets? Also bear in mind that targets like m68k-elf by default build separate multilibs for 68000, 68020, etc. Those libraries will be built with the default as decided by this patch, so code compiled with -m68000 will be link-compatible with the -m68000 libraries. If someone stepped forward to implement --with-float, it would still work regardless of what we do here. --with-soft would add an explicit floating-point option to the command line, avoiding the inference code altogether. Richard ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 9/63] Add -mcpu, -march, -mtune, and related options 2007-01-16 5:38 ` Richard Sandiford @ 2007-01-22 17:12 ` Roman Zippel 0 siblings, 0 replies; 280+ messages in thread From: Roman Zippel @ 2007-01-22 17:12 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches Hi, On Tue, 16 Jan 2007, Richard Sandiford wrote: > Also bear in mind that targets like m68k-elf by default build separate > multilibs for 68000, 68020, etc. Those libraries will be built with > the default as decided by this patch, so code compiled with -m68000 > will be link-compatible with the -m68000 libraries. The point is you can't mix code compiled with -m680?0 and -m68000, e.g. if someone started with 68000 based design and later added support for newer cpus. > If someone stepped forward to implement --with-float, it would still > work regardless of what we do here. Well, it's not that important, I only wanted to mention it. I have no problem to leave this to someone who actually cares, although I guess most who do already use -msoft-float. bye, Roman ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 9/63] Add -mcpu, -march, -mtune, and related options 2007-01-10 10:54 ` [ColdFire 9/63] Add -mcpu, -march, -mtune, and related options Richard Sandiford ` (2 preceding siblings ...) 2007-01-15 18:08 ` Roman Zippel @ 2007-04-12 1:53 ` Roman Zippel 2007-04-18 15:00 ` Richard Sandiford 3 siblings, 1 reply; 280+ messages in thread From: Roman Zippel @ 2007-04-12 1:53 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches Hi, On Wed, 10 Jan 2007, Richard Sandiford wrote: > So far, the m68k port has used separate -m options for each target, > but having 60 separate -m options wasn't very appealing. This patch > therefore follows other ports by adding a -mcpu= option. For consistency, > it also adds an -march option to select an ISA by name and a -mtune option > to tune for a specific microarchitecture. m68k_handle_option maps the old > -m options to a combination of these new ones. I'm currently looking a bit closer at this and I'm a bit confused. These three new options make very little difference at least for the 680x0 part. There is also a crucial difference now, -m680[346]0 don't produce the m68020 define anymore, which needs fixing, e.g. glibc uses it to enable 68020 and higher features. The other m680[346]0 defines are less important, as I don't think there are used much, if at all (most m68k specific code was written for 2.95 or older which didn't produce these defines). From a 680x0 perspective I would prefer something closer to i386. -march would define the basic cpu architecture and the produced code wouldn't run on anything older. -mcpu/-mtune could be synonynous and specify the used cpu optimizations. The TUNE_* macros may need a bit more work too. We have basically three classes: - enable new cpu instructions - enable cpu specific optimizations - disable some (emulated) instructions For example TUNE_68040 does the last two as soon as the 040 is somehow mentioned, but I'd prefer if -m68020-60 would actually not generate 040 specific code sequences and just avoid the emulated instructions. The question is now how ColdFire fits into this. I think something similiar could be done here by letting at least mcpu/mtune accept the same arguments or march could also accept cpu names and then imply a mtune option. I think the current interface is too complex, as the user needs detailed knowledge to figure out the best optimize options. Many current march/mcpu combinations conflict, where I wouldn't expect it and the different syntax from i386 isn't really helping. bye, Roman ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 9/63] Add -mcpu, -march, -mtune, and related options 2007-04-12 1:53 ` Roman Zippel @ 2007-04-18 15:00 ` Richard Sandiford 2007-04-19 0:29 ` Roman Zippel 0 siblings, 1 reply; 280+ messages in thread From: Richard Sandiford @ 2007-04-18 15:00 UTC (permalink / raw) To: Roman Zippel; +Cc: gcc-patches Roman Zippel <zippel@linux-m68k.org> writes: > On Wed, 10 Jan 2007, Richard Sandiford wrote: >> So far, the m68k port has used separate -m options for each target, >> but having 60 separate -m options wasn't very appealing. This patch >> therefore follows other ports by adding a -mcpu= option. For consistency, >> it also adds an -march option to select an ISA by name and a -mtune option >> to tune for a specific microarchitecture. m68k_handle_option maps the old >> -m options to a combination of these new ones. > > I'm currently looking a bit closer at this and I'm a bit confused. These > three new options make very little difference at least for the 680x0 part. It's probably true that it doesn't have much benefit for 680x0 users. I expect the old 68020-40 and 68020-60 options were all that those users really wanted. > There is also a crucial difference now, -m680[346]0 don't produce the > m68020 define anymore, which needs fixing, e.g. glibc uses it to enable > 68020 and higher features. OK, I in turn am confused ;). How did m68020 get defined before the patch? (Do you mean "m68020" or "mc68020" here?) The old macro handling was: if (TARGET_68040_ONLY) \ { \ if (TARGET_68060) \ builtin_define_std ("mc68060"); \ else \ builtin_define_std ("mc68040"); \ } \ else if (TARGET_68060) /* -m68020-60 */ \ { \ builtin_define_std ("mc68060"); \ builtin_define_std ("mc68040"); \ builtin_define_std ("mc68030"); \ builtin_define_std ("mc68020"); \ } \ else if (TARGET_68040) /* -m68020-40 */ \ { \ builtin_define_std ("mc68040"); \ builtin_define_std ("mc68030"); \ builtin_define_std ("mc68020"); \ } \ else if (TARGET_68030) \ builtin_define_std ("mc68030"); \ else if (TARGET_68020) \ builtin_define_std ("mc68020"); \ where -m68060 and -m68040 are handled by the TARGET_68040_ONLY case and -m68030 is handled by the TARGET_68030 case. I also couldn't see a CPP_SPEC that causes mc68020 to be defined for these options. Thus if you really do mean "mc68020", how did it get defined for -m68030, -m68040 and -m68060? > From a 680x0 perspective I would prefer something closer to i386. -march > would define the basic cpu architecture and the produced code wouldn't run > on anything older. -mcpu/-mtune could be synonynous and specify the used > cpu optimizations. Well, ignoring -mcpu, and concentrating solely on 680x0, I think that's what we've already got. E.g. -march=68020 -mtune=68060 should in theory generate pure 68020 code, but tune it for the 68060. (I realise that there's probably more tuning that could done with that combination, but I don't think we _lost_ anything in the transition.) -mcpu is boggier ground, because its name doesn't indicate whether the option is an architecture or tuning macro. I personally think -march and -mtune should be enough, with -march accepting both ISA names and processor names. This is what the MIPS port does, and my understanding was that, at the time we implemented the new MIPS options, we were following what was then considered The Right Way For Target Options to Work. (The older MIPS option handling was such that we ended up redefining it from scratch, with only small heed for backwards compatibility. Ports like x86 don't have that luxury.) However, that's a bikeshed thing, and I gather from recent discussions that I was either misremembering the colour of the bikeshed at the time that the MIPS options were implemented, or the colour has since changed. > The TUNE_* macros may need a bit more work too. We have basically three > classes: > - enable new cpu instructions > - enable cpu specific optimizations > - disable some (emulated) instructions > For example TUNE_68040 does the last two as soon as the 040 is somehow > mentioned, but I'd prefer if -m68020-60 would actually not generate 040 > specific code sequences and just avoid the emulated instructions. To be clear, has the behaviour of -m68020-60 changed? If so, that was unintentional. If not, and you're suggesting a tweak to the traditional behaviour, then you know far better than I what's appropriate here. And TUNE_* macros should never do the first item. They should only choose between two correct sequences. The first item is purely in TARGET_*'s domain. Again, if you know of cases where TUNE_* macros are being used to enable instructions whose presence is not implied by the TARGET_* setting, that is unintentional. (I did try to audit the 680x0 tune/target choices, but given the size of the changes, it's entirely possible I slipped up.) > The question is now how ColdFire fits into this. I think something > similiar could be done here by letting at least mcpu/mtune accept the same > arguments or march could also accept cpu names and then imply a mtune > option. I think the current interface is too complex, as the user needs > detailed knowledge to figure out the best optimize options. Many current > march/mcpu combinations conflict, where I wouldn't expect it and the > different syntax from i386 isn't really helping. Too complex in what situation? The common case is simply to use -mcpu=<my-cpu>. Richard ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 9/63] Add -mcpu, -march, -mtune, and related options 2007-04-18 15:00 ` Richard Sandiford @ 2007-04-19 0:29 ` Roman Zippel 2007-04-19 7:08 ` Richard Sandiford 0 siblings, 1 reply; 280+ messages in thread From: Roman Zippel @ 2007-04-19 0:29 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches Hi, On Wed, 18 Apr 2007, Richard Sandiford wrote: > > I'm currently looking a bit closer at this and I'm a bit confused. These > > three new options make very little difference at least for the 680x0 part. > > It's probably true that it doesn't have much benefit for 680x0 users. > I expect the old 68020-40 and 68020-60 options were all that those > users really wanted. These are interesting for distributions (and as target defaults). User may very well target a specific cpu (with the option to allow the code to run other cpus). So IMO these combinations would be interesting: - -march=68020 -mtune=68020-60 - -march=68020 -mtune=68060 - -march=68060 -mtune=68060 The first would not optimize for a specific cpu and just omit the possibly expensive emulated instructions. The second would optimize for a specific cpu (e.g. via instr costs), but doesn't use new instructions. The last would use all possible optimizations. (BTW a -mtune=generic might be nice to have instead of a 68020-60/ 68030-60/68040-60.) > > There is also a crucial difference now, -m680[346]0 don't produce the > > m68020 define anymore, which needs fixing, e.g. glibc uses it to enable > > 68020 and higher features. > > OK, I in turn am confused ;). How did m68020 get defined before the patch? > (Do you mean "m68020" or "mc68020" here?) The old macro handling was: Sorry, I indeed meant mc68020. > if (TARGET_68040_ONLY) \ > { \ > if (TARGET_68060) \ > builtin_define_std ("mc68060"); \ > else \ > builtin_define_std ("mc68040"); \ > } \ > else if (TARGET_68060) /* -m68020-60 */ \ > { \ > builtin_define_std ("mc68060"); \ > builtin_define_std ("mc68040"); \ > builtin_define_std ("mc68030"); \ > builtin_define_std ("mc68020"); \ > } \ > else if (TARGET_68040) /* -m68020-40 */ \ > { \ > builtin_define_std ("mc68040"); \ > builtin_define_std ("mc68030"); \ > builtin_define_std ("mc68020"); \ > } \ > else if (TARGET_68030) \ > builtin_define_std ("mc68030"); \ > else if (TARGET_68020) \ > builtin_define_std ("mc68020"); \ > > where -m68060 and -m68040 are handled by the TARGET_68040_ONLY case > and -m68030 is handled by the TARGET_68030 case. I also couldn't see > a CPP_SPEC that causes mc68020 to be defined for these options. > Thus if you really do mean "mc68020", how did it get defined for > -m68030, -m68040 and -m68060? 4.1 has a TARGET_OS_CPP_BUILTINS in linux.h which defines it unconditionally (so it's even defined with -m68000 :) ). The question is now what these defines mean. Above does it rather awkwardly as one had to test multiple combinations to figure out the original option and I don't know anything which does that. I would prefer we had two different macros for base archicture and target cpu, but I'm not sure how far we can reuse these macros (IMO only mc68020 is really needed e.g. for glibc). > -mcpu is boggier ground, because its name doesn't indicate whether the > option is an architecture or tuning macro. I personally think -march > and -mtune should be enough, with -march accepting both ISA names and > processor names. Well, that's my basic idea, too. > However, that's a bikeshed thing, and I gather from recent discussions > that I was either misremembering the colour of the bikeshed at the > time that the MIPS options were implemented, or the colour has since > changed. Ok, I must have missed these discussions :), so I mostly go from what i386 does. > > The TUNE_* macros may need a bit more work too. We have basically three > > classes: > > - enable new cpu instructions > > - enable cpu specific optimizations > > - disable some (emulated) instructions > > For example TUNE_68040 does the last two as soon as the 040 is somehow > > mentioned, but I'd prefer if -m68020-60 would actually not generate 040 > > specific code sequences and just avoid the emulated instructions. > > To be clear, has the behaviour of -m68020-60 changed? If so, > that was unintentional. I haven't really checked for this, since the new syntax allows for a few more options, I'd rather concentrate on that. I see two basic options: 1. We basically drop m68020-[46]0 and map it to TUNE_GENERIC instead. 2. We split m68k_tune into a separate m68k_tune_only and add a whole set of TUNE_*_ONLY flags. I'd prefer the first option as it's simpler. > > The question is now how ColdFire fits into this. I think something > > similiar could be done here by letting at least mcpu/mtune accept the same > > arguments or march could also accept cpu names and then imply a mtune > > option. I think the current interface is too complex, as the user needs > > detailed knowledge to figure out the best optimize options. Many current > > march/mcpu combinations conflict, where I wouldn't expect it and the > > different syntax from i386 isn't really helping. > > Too complex in what situation? The common case is simply to use > -mcpu=<my-cpu>. Well, that's the simple case, it gets more complicated if you want to optimize for a range of cpus via march/mtune. Since march and mcpu aren't really usable together I'd think we can do this with two options. Less options which are more flexible at what they accept would also be simpler to use IMO. bye, Roman ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 9/63] Add -mcpu, -march, -mtune, and related options 2007-04-19 0:29 ` Roman Zippel @ 2007-04-19 7:08 ` Richard Sandiford 2007-04-19 7:13 ` Nathan Sidwell ` (3 more replies) 0 siblings, 4 replies; 280+ messages in thread From: Richard Sandiford @ 2007-04-19 7:08 UTC (permalink / raw) To: Roman Zippel; +Cc: gcc-patches, nathan Roman Zippel <zippel@linux-m68k.org> writes: > 4.1 has a TARGET_OS_CPP_BUILTINS in linux.h which defines it > unconditionally (so it's even defined with -m68000 :) ). OK, feel free to add that back from my point of view. I think what m68k.h itself now does is the same as what it used to do (for the option combinations that were available in older compilers). It sounds like you might disagree with that behaviour. If so, feel free to change it from my point of view: I don't have an opinion either way. We already have a set of macros for ColdFire that provide the architecture and tuning info we need. >> However, that's a bikeshed thing, and I gather from recent discussions >> that I was either misremembering the colour of the bikeshed at the >> time that the MIPS options were implemented, or the colour has since >> changed. > > Ok, I must have missed these discussions :), so I mostly go from what i386 > does. I meant off-list discussions, sorry. It was being suggested that ARM was the correct way for these things to be handled (and that, for example, MIPS ought to have a -mcpu option.) >> > The TUNE_* macros may need a bit more work too. We have basically three >> > classes: >> > - enable new cpu instructions >> > - enable cpu specific optimizations >> > - disable some (emulated) instructions >> > For example TUNE_68040 does the last two as soon as the 040 is somehow >> > mentioned, but I'd prefer if -m68020-60 would actually not generate 040 >> > specific code sequences and just avoid the emulated instructions. >> >> To be clear, has the behaviour of -m68020-60 changed? If so, >> that was unintentional. > > I haven't really checked for this, since the new syntax allows for a few > more options, I'd rather concentrate on that. OK, you snipped the next sentence that said: if you're thinking of defining a new behaviour for 680x0, I have no opinion what's best. I'll leave that discussion between you and the maintainers. As far as implementation goes... > I see two basic options: > 1. We basically drop m68020-[46]0 and map it to TUNE_GENERIC instead. > 2. We split m68k_tune into a separate m68k_tune_only and add a whole set > of TUNE_*_ONLY flags. > I'd prefer the first option as it's simpler. ...I balk at the idea of having a m68k_tune_only. ;) >> > The question is now how ColdFire fits into this. I think something >> > similiar could be done here by letting at least mcpu/mtune accept the same >> > arguments or march could also accept cpu names and then imply a mtune >> > option. I think the current interface is too complex, as the user needs >> > detailed knowledge to figure out the best optimize options. Many current >> > march/mcpu combinations conflict, where I wouldn't expect it and the >> > different syntax from i386 isn't really helping. >> >> Too complex in what situation? The common case is simply to use >> -mcpu=<my-cpu>. > > Well, that's the simple case, it gets more complicated if you want to > optimize for a range of cpus via march/mtune. As far as I know, there was no intention of optimising for a _range_ of ColdFire CPUs. We only have single-processor -mtune settings on MIPS, and I've never seen any complaints about that. Trying to support -mtune settings for a range of processors, making decisions that offset one against the other, sounds far too complicated in general. I realise that's what 68020-40 and 68020-60 do, but that's thankfully a small set. (And it sounds like there's doubt about what even those two combined tuning settings should mean.) > Since march and mcpu aren't really usable together I'd think we can do > this with two options. Less options which are more flexible at what > they accept would also be simpler to use IMO. Well, I'm probably the wrong person to argue through that point with you. Especially as I co-maintain a port with just such a set-up. Maybe Nathan (cc:ed) has comments. Richard ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 9/63] Add -mcpu, -march, -mtune, and related options 2007-04-19 7:08 ` Richard Sandiford @ 2007-04-19 7:13 ` Nathan Sidwell 2007-04-19 8:37 ` Andreas Schwab ` (2 subsequent siblings) 3 siblings, 0 replies; 280+ messages in thread From: Nathan Sidwell @ 2007-04-19 7:13 UTC (permalink / raw) To: Roman Zippel, gcc-patches, nathan, richard Richard Sandiford wrote: I've not got much to add beyond what Richard has said. But here is what I have got :) >> Well, that's the simple case, it gets more complicated if you want to >> optimize for a range of cpus via march/mtune. > > As far as I know, there was no intention of optimising for a _range_ of > ColdFire CPUs. The closest one can get to this is something like -march=isaaplus -mtune=cfv3 for instance. And here, IMHO is where -march makes sense -- one's selecting an Instruction Set Architecture. Just to add my 2p I thought march/mcpu/mtune had been declared the way of the future, which is why we did it that way. >> Since march and mcpu aren't really usable together I'd think we can do >> this with two options. Less options which are more flexible at what >> they accept would also be simpler to use IMO. > > Well, I'm probably the wrong person to argue through that point with you. > Especially as I co-maintain a port with just such a set-up. Maybe Nathan > (cc:ed) has comments. I think it's too late to remove one of the march/mcpu/mtune. Roman, as to your m68k-specific comments, I'm sorry if we've managed to regress something, but as you've said, it was (a) twisty and (b) vaguely specified. I think you're in a much better position to provide patches because you understand what the previous behaviour was, and can test it much easier than we can. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan@codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 9/63] Add -mcpu, -march, -mtune, and related options 2007-04-19 7:08 ` Richard Sandiford 2007-04-19 7:13 ` Nathan Sidwell @ 2007-04-19 8:37 ` Andreas Schwab 2007-04-19 9:07 ` Richard Sandiford 2007-04-19 12:02 ` Joseph S. Myers 2007-04-19 13:22 ` Roman Zippel 3 siblings, 1 reply; 280+ messages in thread From: Andreas Schwab @ 2007-04-19 8:37 UTC (permalink / raw) To: richard; +Cc: gcc-patches, nathan, Roman Zippel Richard Sandiford <richard@codesourcery.com> writes: > I meant off-list discussions, sorry. It was being suggested that ARM > was the correct way for these things to be handled (and that, for example, > MIPS ought to have a -mcpu option.) For x86 -mcpu is marked as deprecated. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 9/63] Add -mcpu, -march, -mtune, and related options 2007-04-19 8:37 ` Andreas Schwab @ 2007-04-19 9:07 ` Richard Sandiford 0 siblings, 0 replies; 280+ messages in thread From: Richard Sandiford @ 2007-04-19 9:07 UTC (permalink / raw) To: Andreas Schwab; +Cc: gcc-patches, nathan, Roman Zippel Andreas Schwab <schwab@suse.de> writes: > Richard Sandiford <richard@codesourcery.com> writes: >> I meant off-list discussions, sorry. It was being suggested that ARM >> was the correct way for these things to be handled (and that, for example, >> MIPS ought to have a -mcpu option.) > > For x86 -mcpu is marked as deprecated. Good point. ;) So maybe I wasn't imagining things after all... Richard ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 9/63] Add -mcpu, -march, -mtune, and related options 2007-04-19 7:08 ` Richard Sandiford 2007-04-19 7:13 ` Nathan Sidwell 2007-04-19 8:37 ` Andreas Schwab @ 2007-04-19 12:02 ` Joseph S. Myers 2007-04-19 12:08 ` Richard Sandiford 2007-04-19 13:22 ` Roman Zippel 3 siblings, 1 reply; 280+ messages in thread From: Joseph S. Myers @ 2007-04-19 12:02 UTC (permalink / raw) To: Richard Sandiford; +Cc: Roman Zippel, gcc-patches, nathan On Thu, 19 Apr 2007, Richard Sandiford wrote: > We only have single-processor -mtune settings on MIPS, and I've never > seen any complaints about that. Trying to support -mtune settings for a > range of processors, making decisions that offset one against the other, > sounds far too complicated in general. I realise that's what 68020-40 > and 68020-60 do, but that's thankfully a small set. (And it sounds like > there's doubt about what even those two combined tuning settings should > mean.) Tuning for a range is also what -mtune=generic does for x86, though x86 may be rather a special case in terms of people wishing to build software once that runs on a wide range of systems. -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 9/63] Add -mcpu, -march, -mtune, and related options 2007-04-19 12:02 ` Joseph S. Myers @ 2007-04-19 12:08 ` Richard Sandiford 0 siblings, 0 replies; 280+ messages in thread From: Richard Sandiford @ 2007-04-19 12:08 UTC (permalink / raw) To: Joseph S. Myers; +Cc: Roman Zippel, gcc-patches, nathan "Joseph S. Myers" <joseph@codesourcery.com> writes: > On Thu, 19 Apr 2007, Richard Sandiford wrote: >> We only have single-processor -mtune settings on MIPS, and I've never >> seen any complaints about that. Trying to support -mtune settings for a >> range of processors, making decisions that offset one against the other, >> sounds far too complicated in general. I realise that's what 68020-40 >> and 68020-60 do, but that's thankfully a small set. (And it sounds like >> there's doubt about what even those two combined tuning settings should >> mean.) > > Tuning for a range is also what -mtune=generic does for x86, though x86 > may be rather a special case in terms of people wishing to build software > once that runs on a wide range of systems. Sure. To be clear: I was saying that it was difficult to tune for a _user-specified_ range of processors, which I thought was what Roman was suggesting. Richard ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 9/63] Add -mcpu, -march, -mtune, and related options 2007-04-19 7:08 ` Richard Sandiford ` (2 preceding siblings ...) 2007-04-19 12:02 ` Joseph S. Myers @ 2007-04-19 13:22 ` Roman Zippel 2007-04-20 17:35 ` Ian Lance Taylor 3 siblings, 1 reply; 280+ messages in thread From: Roman Zippel @ 2007-04-19 13:22 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches, nathan Hi, On Thu, 19 Apr 2007, Richard Sandiford wrote: > Roman Zippel <zippel@linux-m68k.org> writes: > > 4.1 has a TARGET_OS_CPP_BUILTINS in linux.h which defines it > > unconditionally (so it's even defined with -m68000 :) ). > > OK, feel free to add that back from my point of view. > > I think what m68k.h itself now does is the same as what it used to do > (for the option combinations that were available in older compilers). > It sounds like you might disagree with that behaviour. If so, feel free > to change it from my point of view: I don't have an opinion either way. > We already have a set of macros for ColdFire that provide the > architecture and tuning info we need. Well, I just think there are pretty useless. It would be nice to have something that maps more directly to -march, I'll have to think about it. > I meant off-list discussions, sorry. It was being suggested that ARM > was the correct way for these things to be handled (and that, for example, > MIPS ought to have a -mcpu option.) I looked over the other ports and ARM is quite unique in this behaviour. i386 is unique in that -mcpu maps to -mtune (historical reasons I guess). Everything else has -mcpu and/or -march with an optional -mtune and I would strongly tend to do the same (with the weak tendency to just use -march). > > Well, that's the simple case, it gets more complicated if you want to > > optimize for a range of cpus via march/mtune. > > As far as I know, there was no intention of optimising for a _range_ of > ColdFire CPUs. > > We only have single-processor -mtune settings on MIPS, and I've never > seen any complaints about that. Trying to support -mtune settings for a > range of processors, making decisions that offset one against the other, > sounds far too complicated in general. I realise that's what 68020-40 > and 68020-60 do, but that's thankfully a small set. There is maybe a little misunderstanding, I don't care about arbitrary ranges. I'd like something closer to primary targets like ppc/sparc or mips, where one option defines the basic instruction set and another option defines how they are used. -m68020-[46]0 could IMO just map to -mtune=generic. > (And it sounds like > there's doubt about what even those two combined tuning settings should > mean.) Well, -m68020-60 would just disable a few more instructions, which are emulated on a 68060. bye, Roman ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 9/63] Add -mcpu, -march, -mtune, and related options 2007-04-19 13:22 ` Roman Zippel @ 2007-04-20 17:35 ` Ian Lance Taylor 0 siblings, 0 replies; 280+ messages in thread From: Ian Lance Taylor @ 2007-04-20 17:35 UTC (permalink / raw) To: Roman Zippel; +Cc: Richard Sandiford, gcc-patches, nathan Roman Zippel <zippel@linux-m68k.org> writes: > Everything else has -mcpu and/or -march with an optional -mtune and I > would strongly tend to do the same (with the weak tendency to just use > -march). In my experience that main advantage of distinguishing -mcpu and -march is that specific versions of CPUs may require specific fixes to work around errors in the implementation of the ISA. We see this on MIPS for -mfix-r4000, -mfix-r4400, etc. When I've implemented backends, I arrange for -mcpu=XXX to enable these fixups, as distinct from -march=XXX which simply sets the ISA. This is of course most useful when there are different versions of a processor intended to support the same ISA. Ian ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 8/63] Share ASM_SPEC code between targets 2007-01-10 10:46 ` [ColdFire 8/63] Share ASM_SPEC code between targets Richard Sandiford 2007-01-10 10:54 ` [ColdFire 9/63] Add -mcpu, -march, -mtune, and related options Richard Sandiford @ 2007-01-10 18:10 ` Jeffrey Law 1 sibling, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-01-10 18:10 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches On Wed, 2007-01-10 at 10:46 +0000, Richard Sandiford wrote: > Each m68k subtarget has its own ASM_SPEC to pass down target selection > options. Some of these specs are more exhaustive than others. > > This patch defines an %(asm_cpu_spec) which can be used by all targets, > and which passes down all known target selection options. The patch is > needed by the forthcoming -mcpu=* and -march=* support. > > Richard > > > gcc/ > 200x-xx-xx Richard Sandiford <richard@codesourcery.com> > Nathan Sidwell <nathan@codesourcery.com> > > * config/m68k/m68k.h (ASM_CPU_SPEC, ASM_SPEC, EXTRA_SPECS) > (SUBTARGET_EXTRA_SPECS): New macros. > * config/m68k/linux.h (ASM_SPEC): Remove CPU flags; > use %(asm_cpu_spec) instead. > * config/m68k/m68k-none.h (ASM_SPEC): Likewise. > * config/m68k/openbsd.h (ASM_SPEC): Likewise. > * config/m68k/netbsd-elf.h (ASM_SPEC): Likewise. > (EXTRA_SPECS): Rename to... > (SUBTARGET_EXTRA_SPECS): ...this. OK. Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 7/63] Default target selection and --with-cpu support 2007-01-10 10:45 ` [ColdFire 7/63] Default target selection and --with-cpu support Richard Sandiford 2007-01-10 10:46 ` [ColdFire 8/63] Share ASM_SPEC code between targets Richard Sandiford @ 2007-01-10 18:09 ` Jeffrey Law 2007-01-10 18:11 ` Richard Sandiford 1 sibling, 1 reply; 280+ messages in thread From: Jeffrey Law @ 2007-01-10 18:09 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches On Wed, 2007-01-10 at 10:45 +0000, Richard Sandiford wrote: > The m68k port allows the default target to be specified at configure time. > However, the code that does this predates OPTION_DEFAULT_SPECS and uses a > hairy system of default masks instead. > > This patch: > > (1) extends the existing GNU/Linux --with-cpu code to all m68k targets. > > (2) allows --with-cpu=m68000 and --with-cpu=m68010 too. > > (3) makes each m68k-* configuration set the default target using > default_m68k_cpu. Currently all m68k-* targets use a default > of 68020, but the associated ColdFire configurations do not use > the same defaults as each other, so it seemed like a good idea > to be consistent. > > (4) makes m680[012]0-* configurations use the first part of the triplet > as the default target. > > (5) uses OPTIONS_DEFAULT_SPECS to make sure that a CPU option is always > present on the command line, and cleans up config/m68k accordingly. > Note that unlike other targets, the value of with_cpu is a > command-line option without the leading "-"; this is to support > both the traditional -m<cpu> and upcoming -mcpu=<cpu> options. > > (6) makes MASK_68881 the default. This is not a behavioural change: > if --with-cpu=m68020 is given or implied, the default will be > hard float, while if any other --with-cpu=mfoo is given, the mask > will be set or cleared when the -mfoo option is processed. > > One disadvantage of this patch in isolation is that you must remember > to pass the CPU option when invoking cc1 directly. A later patch fixes > that, so that cc1's default is the same as the driver's. OK. But please hold off installing until I hit the patch which fixes the need to pass the CPU option down to cc1. If I haven't ack'd that patch in 24hrs please ping me (if you happen to know it's patch number in the set of 63, that would help :-) jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 7/63] Default target selection and --with-cpu support 2007-01-10 18:09 ` [ColdFire 7/63] Default target selection and --with-cpu support Jeffrey Law @ 2007-01-10 18:11 ` Richard Sandiford 0 siblings, 0 replies; 280+ messages in thread From: Richard Sandiford @ 2007-01-10 18:11 UTC (permalink / raw) To: law; +Cc: gcc-patches Jeffrey Law <law@redhat.com> writes: > OK. But please hold off installing until I hit the patch which fixes > the need to pass the CPU option down to cc1. Understood, thanks. And thanks for taking the time to look at all this stuff. > If I haven't ack'd that patch in 24hrs please ping me (if you happen > to know it's patch number in the set of 63, that would help :-) It's number 9. Richard ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 6/63] Make gcc honour -m68010 2007-01-10 10:39 ` [ColdFire 6/63] Make gcc honour -m68010 Richard Sandiford 2007-01-10 10:45 ` [ColdFire 7/63] Default target selection and --with-cpu support Richard Sandiford @ 2007-01-10 18:07 ` Jeffrey Law 1 sibling, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-01-10 18:07 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches On Wed, 2007-01-10 at 10:39 +0000, Richard Sandiford wrote: > gcc already recognises a -m68010 option, but it only passes the > option down to the assembler; it does nothing with the option itself. > Comments show that someone did want gcc to distinguish between > the 68000 and 68010, but for some reason they never added the code. It's been a *very* long time, but IIRC the number of differences between the 68000 and 68010 that are of interest to gcc are *very* minor and there weren't a whole lot of 68010 users out there to make it worth the effort. > > gcc/ > * config.gcc (m68010-*-netbsdelf*): Add MASK_68010. > (m68k*-*-netbsdelf*, m68k*-*-openbsd*, m68k*-linux*): Add > MASK_68010 alongside MASK_68020. > * doc/invoke.texi: Document -m68010. > * config/m68k/m68k.opt (m68010): New. > * config/m68k/m68k.h (TARGET_CPU_CPP_BUILTINS): Define mc68010 > if TUNE_68010. > (TUNE_68010): New macro. > * config/m68k/m68k-none.h (M68K_CPU_m68k, M68K_CPU_m68010) > (M68K_CPU_m68020, M68K_CPU_m68030, M68K_CPU_m68040) > (M68K_CPU_m68332): Add MASK_68010. > * config/m68k/linux.h (TARGET_DEFAULT): Add MASK_68010 to > fallback definition. > * config/m68k/netbsd-elf.h (CPP_CPU_SPEC): Remove now-redundant > defines. > * config/m68k/m68k.c (MASK_ALL_CPU_BITS): Add MASK_68010. > (m68k_handle_option): Handle OPT_m68010. Add MASK_68010 > to all entries that use MASK_68020. > (output_move_simode_const, output_move_himode, output_move_qimode) > (output_move_stricthi, output_move_strictqi): Use TARGET_68010 > instead of TARGET_68020 to select clr behavior. Remove comment > about there being no TARGET_68010. > * config/m68k/m68k.md: Likewise throughout. OK. Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 4/63] TARGET_COLDFIRE_FPU vs. TARGET_CFV4E 2007-01-10 10:35 ` [ColdFire 4/63] TARGET_COLDFIRE_FPU vs. TARGET_CFV4E Richard Sandiford 2007-01-10 10:37 ` [ColdFire 5/63] Introduce TARGET_ISAB Richard Sandiford 2007-01-10 10:39 ` [ColdFire 6/63] Make gcc honour -m68010 Richard Sandiford @ 2007-01-10 17:52 ` Jeffrey Law 2 siblings, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-01-10 17:52 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches On Wed, 2007-01-10 at 10:35 +0000, Richard Sandiford wrote: > Most of ColdFire FPU addressing code is conditional on TARGET_COLDFIRE_FPU, > but two pieces are conditional on TARGET_CFV4E instead. Specifically: > > && (INTVAL (XEXP (X, 1)) == 2 \ > || INTVAL (XEXP (X, 1)) == 4 \ > || (INTVAL (XEXP (X, 1)) == 8 \ > && (TARGET_CFV4E || !TARGET_COLDFIRE))))) > > and: > > if (ch && GET_CODE (XEXP (X, 1)) == REG \ > && GET_CODE (XEXP (X, 0)) == REG) \ > { if (TARGET_CFV4E && GET_MODE_CLASS (MODE) == MODE_FLOAT) \ > { COPY_ONCE (X); X = force_operand (X, 0);} \ > goto WIN; } \ > > TARGET_CFV4E is currently defined as TARGET_COLDFIRE_FPU, so there is > no behavioural difference between the two. However, later patches in > the series separate TARGET_COLDFIRE_FPU from TARGET_CFV4E, and I don't > think the choice of macro is conceptually right in these two cases. > > For the first hunk: page 2-2 of the ColdFire Reference Manual makes > it clear that a factor of 8 is only allowed if an FPU is present. > It therefore seems logical to guard the first code with > TARGET_COLDFIRE_FPU. > > For the second hunk: the ColdFire FPU does not allow indexed addressing > modes, so as a practical measure, GO_IF_LEGITIMATE_ADDRESS stops any > floating-point MEM from using indexes. This G_I_L_A code is already > conditional on TARGET_COLDFIRE_FPU, and because the second hunk quoted > above is part of the associated LEGITIMIZE_ADDRESS code, it too should > use TARGET_COLDFIRE_FPU. > > Richard > > > gcc/ > 200x-xx-xx Julian Brown <julian@codesourcery.com> > > * config/m68k/m68k.h (LEGITIMATE_INDEX_P, LEGITIMIZE_ADDRESS): Use > TARGET_COLDFIRE_FPU instead of TARGET_CFV4E. OK. jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 3/63] Add TUNE_68040_60 2007-01-10 10:34 ` [ColdFire 3/63] Add TUNE_68040_60 Richard Sandiford 2007-01-10 10:35 ` [ColdFire 4/63] TARGET_COLDFIRE_FPU vs. TARGET_CFV4E Richard Sandiford @ 2007-01-10 17:48 ` Jeffrey Law 1 sibling, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-01-10 17:48 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches On Wed, 2007-01-10 at 10:34 +0000, Richard Sandiford wrote: > Some bits of tuning code apply to both the 68040 and 68060. This patch > simply adds a single macro for that, along the lines of the TUNE_68000_10 > macro added in the last patch. > > Richard > > > gcc/ > 200x-xx-xx Julian Brown <julian@codesourcery.com> > > * config/m68k/m68k.h (TUNE_68040_60): New macro. > * config/m68k/m68k.c (standard_68881_constant_p): Use it. > * config/m68k/m68k.md: Likewise. OK. Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 2/63] Use TUNE_* macros instead of TARGET_* macros 2007-01-10 10:33 ` [ColdFire 2/63] Use TUNE_* macros instead of TARGET_* macros Richard Sandiford 2007-01-10 10:34 ` [ColdFire 3/63] Add TUNE_68040_60 Richard Sandiford @ 2007-01-10 17:47 ` Jeffrey Law 2007-01-15 17:16 ` Roman Zippel 2 siblings, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-01-10 17:47 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches On Wed, 2007-01-10 at 10:32 +0000, Richard Sandiford wrote: > The current m68k TARGET_* macros are confusing. Some of them > (like TARGET_68020 and TARGET_68040_ONLY) control the target ISA > while others (like TARGET_68040 and TARGET_68060) control tuning. > > Other backends have standardised on TARGET_* for ISA selection > and TUNE_* for tuning control. This patch makes the same > distinction for m68k. There should be no behavioural changes. > > Later patches in the series get rid of the old tuning-related > TARGET_* macros themselves; this patch simply adds TUNE_* > wrappers for them. Later patches also add more TUNE_* macros > and an -mtune command-line option. > > Richard > > > gcc/ > 200x-xx-xx Julian Brown <julian@codesourcery.com> > Richard Sandiford <richard@codesourcery.com> > > * config/m68k/m68k.h (TARGET_CPU_CPP_BUILTINS): Use TUNE_68030 > instead of TARGET_68030, TUNE_68040 instead of TARGET_68040, > TUNE_68060 instead of TARGET_68060 and TUNE_CPU32 instead of > TARGET_CPU32. > (TARGET_CPU32): Rename to... > (TUNE_CPU32): ...this. > (TUNE_68000_10, TUNE_68030, TUNE_68040, TUNE_68060) > (TUNE_CFV2): New macros. > * config/m68k/netbsd-elf.h (LONG_DOUBLE_TYPE_SIZE): Simplify; > remove conditions that are implied by TARGET_68020. > * config/m68k/m68k.c (m68k_output_function_prologue): Use TUNE_68040 > instead of TARGET_68040 and TUNE_CPU32 instead of TARGET_CPU32. > (m68k_output_function_epilogue): Likewise. > (m68k_rtx_costs): Likewise. Use TUNE_68060 instead of TARGET_68060 > and TUNE_CFV2 instead of TARGET_5200. Use TUNE_68000_10 instead of > "!TARGET_68020 && !TARGET_COLDFIRE" to choose between 68000 and > non-68000 timings. Refactor multiplication and division costs. > (output_addsi3): Use TUNE_68040 instead of TARGET_68040 and > TUNE_CPU32 instead of TARGET_CPU32. > (standard_68881_constant_p): Use TUNE_68040 instead of TARGET_68040 > and TUNE_68060 instead of TARGET_68060. > * config/m68k/m68k.md: Use TUNE_68040 instead of TARGET_68040, > TUNE_68060 instead of TARGET_68060, and TUNE_CPU32 instead of > TARGET_CPU32. > (movsi_const0): Use TUNE_68000_10 rather than "!TARGET_68020 > && !TARGET_COLDFIRE" to choose between moveq and clr. > Likewise in the unnamed movsf pattern. > (ashlsi_17_24, lshrsi_17_24): Guard with TUNE_68000_10 rather than > "!TARGET_68020 && !TARGET_COLDFIRE". Likewise the unnamed > ashiftrt pattern. OK. Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 2/63] Use TUNE_* macros instead of TARGET_* macros 2007-01-10 10:33 ` [ColdFire 2/63] Use TUNE_* macros instead of TARGET_* macros Richard Sandiford 2007-01-10 10:34 ` [ColdFire 3/63] Add TUNE_68040_60 Richard Sandiford 2007-01-10 17:47 ` [ColdFire 2/63] Use TUNE_* macros instead of TARGET_* macros Jeffrey Law @ 2007-01-15 17:16 ` Roman Zippel 2007-01-15 17:57 ` Andreas Schwab 2 siblings, 1 reply; 280+ messages in thread From: Roman Zippel @ 2007-01-15 17:16 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches Hi, On Wed, 10 Jan 2007, Richard Sandiford wrote: > @@ -618,13 +618,13 @@ (define_insn "movsi_const0" > if (ADDRESS_REG_P (operands[0])) > { > /* On the '040, 'subl an,an' takes 2 clocks while lea takes only 1 */ > - if (!TARGET_68040 && !TARGET_68060) > + if (!TUNE_68040 && !TUNE_68060) > return "sub%.l %0,%0"; > else Hmm, the comment is correct, but the test doesn't quite match... bye, Roman ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 2/63] Use TUNE_* macros instead of TARGET_* macros 2007-01-15 17:16 ` Roman Zippel @ 2007-01-15 17:57 ` Andreas Schwab 2007-01-15 18:06 ` Roman Zippel 0 siblings, 1 reply; 280+ messages in thread From: Andreas Schwab @ 2007-01-15 17:57 UTC (permalink / raw) To: Roman Zippel; +Cc: Richard Sandiford, gcc-patches Roman Zippel <zippel@linux-m68k.org> writes: > On Wed, 10 Jan 2007, Richard Sandiford wrote: > >> @@ -618,13 +618,13 @@ (define_insn "movsi_const0" >> if (ADDRESS_REG_P (operands[0])) >> { >> /* On the '040, 'subl an,an' takes 2 clocks while lea takes only 1 */ >> - if (!TARGET_68040 && !TARGET_68060) >> + if (!TUNE_68040 && !TUNE_68060) >> return "sub%.l %0,%0"; >> else > > Hmm, the comment is correct, but the test doesn't quite match... Why do you think so? When tuning for 680x0 with x < 4 it is better to use "sub" since it is smaller. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 2/63] Use TUNE_* macros instead of TARGET_* macros 2007-01-15 17:57 ` Andreas Schwab @ 2007-01-15 18:06 ` Roman Zippel 2007-01-15 18:32 ` Andreas Schwab 0 siblings, 1 reply; 280+ messages in thread From: Roman Zippel @ 2007-01-15 18:06 UTC (permalink / raw) To: Andreas Schwab; +Cc: Richard Sandiford, gcc-patches Hi, On Mon, 15 Jan 2007, Andreas Schwab wrote: > >> @@ -618,13 +618,13 @@ (define_insn "movsi_const0" > >> if (ADDRESS_REG_P (operands[0])) > >> { > >> /* On the '040, 'subl an,an' takes 2 clocks while lea takes only 1 */ > >> - if (!TARGET_68040 && !TARGET_68060) > >> + if (!TUNE_68040 && !TUNE_68060) > >> return "sub%.l %0,%0"; > >> else > > > > Hmm, the comment is correct, but the test doesn't quite match... > > Why do you think so? When tuning for 680x0 with x < 4 it is better to use > "sub" since it is smaller. Because AFAICT the tuning only makes sense if x != 4. bye, Roman ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 2/63] Use TUNE_* macros instead of TARGET_* macros 2007-01-15 18:06 ` Roman Zippel @ 2007-01-15 18:32 ` Andreas Schwab 0 siblings, 0 replies; 280+ messages in thread From: Andreas Schwab @ 2007-01-15 18:32 UTC (permalink / raw) To: Roman Zippel; +Cc: Richard Sandiford, gcc-patches Roman Zippel <zippel@linux-m68k.org> writes: > Hi, > > On Mon, 15 Jan 2007, Andreas Schwab wrote: > >> >> @@ -618,13 +618,13 @@ (define_insn "movsi_const0" >> >> if (ADDRESS_REG_P (operands[0])) >> >> { >> >> /* On the '040, 'subl an,an' takes 2 clocks while lea takes only 1 */ >> >> - if (!TARGET_68040 && !TARGET_68060) >> >> + if (!TUNE_68040 && !TUNE_68060) >> >> return "sub%.l %0,%0"; >> >> else >> > >> > Hmm, the comment is correct, but the test doesn't quite match... >> >> Why do you think so? When tuning for 680x0 with x < 4 it is better to use >> "sub" since it is smaller. > > Because AFAICT the tuning only makes sense if x != 4. Ok, I got your point now. Would you mind creating a bug so that this won't be forgotten? Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: [ColdFire 1/63] Retabulate TARGET_CPU_CPP_BUILTINS 2007-01-10 10:31 ` [ColdFire 1/63] Retabulate TARGET_CPU_CPP_BUILTINS Richard Sandiford 2007-01-10 10:33 ` [ColdFire 2/63] Use TUNE_* macros instead of TARGET_* macros Richard Sandiford @ 2007-01-10 17:47 ` Jeffrey Law 1 sibling, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-01-10 17:47 UTC (permalink / raw) To: Richard Sandiford; +Cc: gcc-patches On Wed, 2007-01-10 at 10:31 +0000, Richard Sandiford wrote: > Some of the later patches add lines to TARGET_CPU_CPP_BUITINS that > stretch beyond the current backslash column. This patch simply makes > room for them by moving the column to the right. The patch is obvious > if the later patches are OK, but I'm posting it separately for ease > of review. > > Richard > > > gcc/ > * config/m68k/m68k.h (TARGET_CPU_CPP_BUILTINS): Increase amount > of tabbing before backslashes. OK. Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: ColdFire submission 2007-01-10 10:30 ColdFire submission Richard Sandiford 2007-01-10 10:31 ` [ColdFire 1/63] Retabulate TARGET_CPU_CPP_BUILTINS Richard Sandiford @ 2007-01-10 22:58 ` Steven Bosscher 2007-01-10 23:13 ` Jeffrey Law 1 sibling, 1 reply; 280+ messages in thread From: Steven Bosscher @ 2007-01-10 22:58 UTC (permalink / raw) To: gcc-patches; +Cc: Richard Sandiford On Wednesday 10 January 2007 11:30, Richard Sandiford wrote: > I'm about to submit the ColdFire 4.3 project: > > http://gcc.gnu.org/wiki/Coldfire_changes > > As usual with this sort of thing, a single patch would be too big > to review as a unit. I've therefore tried to split it into smaller, > more managable, pieces. There ended up being 63 in all. There's one missing!!! Where's the patch to turn m68k into a CCreg port? ;-) I had hoped that CC0-ports would be in maintenance mode only, but that is apparently not the case, unfortunately. This looks like an almost total rewrite of the m68k backend. Anyway, thanks for splitting up the patches though. I see there's a discussion about that going on elsewhere. IMHO this is nice reading. Gr. Steven ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: ColdFire submission 2007-01-10 22:58 ` ColdFire submission Steven Bosscher @ 2007-01-10 23:13 ` Jeffrey Law 2007-01-10 23:36 ` Mike Stump 0 siblings, 1 reply; 280+ messages in thread From: Jeffrey Law @ 2007-01-10 23:13 UTC (permalink / raw) To: Steven Bosscher; +Cc: gcc-patches, Richard Sandiford On Thu, 2007-01-11 at 00:00 +0100, Steven Bosscher wrote: > On Wednesday 10 January 2007 11:30, Richard Sandiford wrote: > > I'm about to submit the ColdFire 4.3 project: > > > > http://gcc.gnu.org/wiki/Coldfire_changes > > > > As usual with this sort of thing, a single patch would be too big > > to review as a unit. I've therefore tried to split it into smaller, > > more managable, pieces. There ended up being 63 in all. > > There's one missing!!! Where's the patch to turn m68k into a CCreg port? :-) Note that his patch does convert the m68k to RTL prologue/epilogues. How many more textual prologue/epilogue targets are left after this patch? > I had hoped that CC0-ports would be in maintenance mode only, but that is > apparently not the case, unfortunately. This looks like an almost total > rewrite of the m68k backend. Far from a rewrite. It really doesn't hit the code generation stuff all that hard. There's a ton of configury fixes/cleanups some codegen tweaks, rtl prologues/epilogues, significant address mode changes some call/return changes, etc. But it's really not huge relative to the size of the m68k port. Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: ColdFire submission 2007-01-10 23:13 ` Jeffrey Law @ 2007-01-10 23:36 ` Mike Stump 2007-01-10 23:41 ` Andrew Pinski ` (3 more replies) 0 siblings, 4 replies; 280+ messages in thread From: Mike Stump @ 2007-01-10 23:36 UTC (permalink / raw) To: law; +Cc: Steven Bosscher, gcc-patches, Richard Sandiford On Jan 10, 2007, at 3:12 PM, Jeffrey Law wrote: > How many more textual prologue/epilogue targets are left after this > patch? arc, arm, avr, cris, frv, ia64, m32r, mips, mmix, pa, pdp11, rs6000, score, sparc and vax, if I counted that right. Seems like arm, mips, pa, rs6000, sparc and score should have been fixed by now... ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: ColdFire submission 2007-01-10 23:36 ` Mike Stump @ 2007-01-10 23:41 ` Andrew Pinski 2007-01-10 23:47 ` Ian Lance Taylor ` (2 subsequent siblings) 3 siblings, 0 replies; 280+ messages in thread From: Andrew Pinski @ 2007-01-10 23:41 UTC (permalink / raw) To: Mike Stump; +Cc: Steven Bosscher, gcc-patches, Richard Sandiford, law > > On Jan 10, 2007, at 3:12 PM, Jeffrey Law wrote: > > How many more textual prologue/epilogue targets are left after this > > patch? > > arc, arm, avr, cris, frv, ia64, m32r, mips, mmix, pa, pdp11, rs6000, > score, sparc and vax, if I counted that right. > > Seems like arm, mips, pa, rs6000, sparc and score should have been > fixed by now... rs6000 and sparc are both "fixed". rs6000 provides both ways, though I don't know how well supported the textual pro/epilogue option is now. Thanks, Andrew Pinski ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: ColdFire submission 2007-01-10 23:36 ` Mike Stump 2007-01-10 23:41 ` Andrew Pinski @ 2007-01-10 23:47 ` Ian Lance Taylor 2007-01-10 23:47 ` Eric Christopher 2007-01-11 0:04 ` Jeffrey Law 3 siblings, 0 replies; 280+ messages in thread From: Ian Lance Taylor @ 2007-01-10 23:47 UTC (permalink / raw) To: Mike Stump; +Cc: law, Steven Bosscher, gcc-patches, Richard Sandiford Mike Stump <mrs@apple.com> writes: > On Jan 10, 2007, at 3:12 PM, Jeffrey Law wrote: > > How many more textual prologue/epilogue targets are left after this > > patch? > > arc, arm, avr, cris, frv, ia64, m32r, mips, mmix, pa, pdp11, rs6000, > score, sparc and vax, if I counted that right. > > Seems like arm, mips, pa, rs6000, sparc and score should have been > fixed by now... How are you counting? The MIPS, for example, outputs some stuff in TARGET_ASM_FUNCTION_PROLOGUE, but all the real code (except for one instruction in the old o32 mode) is in mips_expand_prologue. Ian ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: ColdFire submission 2007-01-10 23:36 ` Mike Stump 2007-01-10 23:41 ` Andrew Pinski 2007-01-10 23:47 ` Ian Lance Taylor @ 2007-01-10 23:47 ` Eric Christopher 2007-01-11 0:48 ` Mike Stump 2007-01-11 0:04 ` Jeffrey Law 3 siblings, 1 reply; 280+ messages in thread From: Eric Christopher @ 2007-01-10 23:47 UTC (permalink / raw) To: Mike Stump; +Cc: law, Steven Bosscher, gcc-patches, Richard Sandiford On Jan 10, 2007, at 3:34 PM, Mike Stump wrote: > On Jan 10, 2007, at 3:12 PM, Jeffrey Law wrote: >> How many more textual prologue/epilogue targets are left after >> this patch? > > arc, arm, avr, cris, frv, ia64, m32r, mips, mmix, pa, pdp11, > rs6000, score, sparc and vax, if I counted that right. > > Seems like arm, mips, pa, rs6000, sparc and score should have been > fixed by now... For mips the prologue is rtl based the textual bits are surrounding things similar to alpha. Unless I'm missing what the question is... -eric ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: ColdFire submission 2007-01-10 23:47 ` Eric Christopher @ 2007-01-11 0:48 ` Mike Stump 2007-01-11 0:53 ` Eric Christopher 0 siblings, 1 reply; 280+ messages in thread From: Mike Stump @ 2007-01-11 0:48 UTC (permalink / raw) To: Eric Christopher; +Cc: law, Steven Bosscher, gcc-patches, Richard Sandiford On Jan 10, 2007, at 3:46 PM, Eric Christopher wrote: > For mips the prologue is rtl based the textual bits are surrounding > things similar to alpha. Unless I'm missing what the question is... mips/mips.c:1098:#undef TARGET_ASM_FUNCTION_PROLOGUE mips/mips.c:1099:#define TARGET_ASM_FUNCTION_PROLOGUE mips_output_function_prologue The alpha doesn't do that. :-) Though, now I see: alpha.c:#undef TARGET_ASM_FUNCTION_END_PROLOGUE alpha.c:#define TARGET_ASM_FUNCTION_END_PROLOGUE alpha_output_function_end_prologue so I only answered which ports had prologue bits, I didn't search for textual epilogue bits. ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: ColdFire submission 2007-01-11 0:48 ` Mike Stump @ 2007-01-11 0:53 ` Eric Christopher 2007-01-11 8:09 ` Richard Sandiford 0 siblings, 1 reply; 280+ messages in thread From: Eric Christopher @ 2007-01-11 0:53 UTC (permalink / raw) To: Mike Stump; +Cc: law, Steven Bosscher, gcc-patches, Richard Sandiford On Jan 10, 2007, at 4:46 PM, Mike Stump wrote: > On Jan 10, 2007, at 3:46 PM, Eric Christopher wrote: >> For mips the prologue is rtl based the textual bits are >> surrounding things similar to alpha. Unless I'm missing what the >> question is... > > mips/mips.c:1098:#undef TARGET_ASM_FUNCTION_PROLOGUE > mips/mips.c:1099:#define TARGET_ASM_FUNCTION_PROLOGUE > mips_output_function_prologue > > The alpha doesn't do that. :-) Though, now I see: I guess I could put the code in ASM_DECLARE_FUNCTION_NAME... -eric ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: ColdFire submission 2007-01-11 0:53 ` Eric Christopher @ 2007-01-11 8:09 ` Richard Sandiford 2007-01-11 14:48 ` Eric Christopher 0 siblings, 1 reply; 280+ messages in thread From: Richard Sandiford @ 2007-01-11 8:09 UTC (permalink / raw) To: Eric Christopher; +Cc: Mike Stump, law, Steven Bosscher, gcc-patches Eric Christopher <echristo@apple.com> writes: > On Jan 10, 2007, at 4:46 PM, Mike Stump wrote: > >> On Jan 10, 2007, at 3:46 PM, Eric Christopher wrote: >>> For mips the prologue is rtl based the textual bits are >>> surrounding things similar to alpha. Unless I'm missing what the >>> question is... >> >> mips/mips.c:1098:#undef TARGET_ASM_FUNCTION_PROLOGUE >> mips/mips.c:1099:#define TARGET_ASM_FUNCTION_PROLOGUE >> mips_output_function_prologue >> >> The alpha doesn't do that. :-) Though, now I see: > > I guess I could put the code in ASM_DECLARE_FUNCTION_NAME... Heh. Please don't ;) Like Jeff, I thought the big issue wasn't whether ports were still using these hooks to output text, but whether they were using them to output instructions. Richard ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: ColdFire submission 2007-01-11 8:09 ` Richard Sandiford @ 2007-01-11 14:48 ` Eric Christopher 0 siblings, 0 replies; 280+ messages in thread From: Eric Christopher @ 2007-01-11 14:48 UTC (permalink / raw) To: Richard Sandiford; +Cc: Mike Stump, law, Steven Bosscher, gcc-patches On Jan 11, 2007, at 12:09 AM, Richard Sandiford wrote: > Eric Christopher <echristo@apple.com> writes: >> On Jan 10, 2007, at 4:46 PM, Mike Stump wrote: >> >>> On Jan 10, 2007, at 3:46 PM, Eric Christopher wrote: >>>> For mips the prologue is rtl based the textual bits are >>>> surrounding things similar to alpha. Unless I'm missing what the >>>> question is... >>> >>> mips/mips.c:1098:#undef TARGET_ASM_FUNCTION_PROLOGUE >>> mips/mips.c:1099:#define TARGET_ASM_FUNCTION_PROLOGUE >>> mips_output_function_prologue >>> >>> The alpha doesn't do that. :-) Though, now I see: >> >> I guess I could put the code in ASM_DECLARE_FUNCTION_NAME... > > Heh. Please don't ;) Like Jeff, I thought the big issue wasn't > whether ports were still using these hooks to output text, > but whether they were using them to output instructions. Yeah, I wasn't planning on it :) It was one of those "if we're the last port doing this and people really want to delete it..." -eric ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: ColdFire submission 2007-01-10 23:36 ` Mike Stump ` (2 preceding siblings ...) 2007-01-10 23:47 ` Eric Christopher @ 2007-01-11 0:04 ` Jeffrey Law 2007-01-11 0:45 ` Mike Stump 2007-01-11 7:36 ` Eric Botcazou 3 siblings, 2 replies; 280+ messages in thread From: Jeffrey Law @ 2007-01-11 0:04 UTC (permalink / raw) To: Mike Stump; +Cc: Steven Bosscher, gcc-patches, Richard Sandiford On Wed, 2007-01-10 at 15:34 -0800, Mike Stump wrote: > On Jan 10, 2007, at 3:12 PM, Jeffrey Law wrote: > > How many more textual prologue/epilogue targets are left after this > > patch? > > arc, arm, avr, cris, frv, ia64, m32r, mips, mmix, pa, pdp11, rs6000, > score, sparc and vax, if I counted that right. > > Seems like arm, mips, pa, rs6000, sparc and score should have been > fixed by now... PA uses RTL prologues/epilogues and has for about a decade. No idea why you'd think otherwise. I'm pretty sure the SPARC uses RTL prologues/epilogues as well. Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: ColdFire submission 2007-01-11 0:04 ` Jeffrey Law @ 2007-01-11 0:45 ` Mike Stump 2007-01-11 1:05 ` Jeffrey Law 2007-01-11 7:36 ` Eric Botcazou 1 sibling, 1 reply; 280+ messages in thread From: Mike Stump @ 2007-01-11 0:45 UTC (permalink / raw) To: law; +Cc: Steven Bosscher, gcc-patches, Richard Sandiford On Jan 10, 2007, at 4:03 PM, Jeffrey Law wrote: > PA uses RTL prologues/epilogues and has for about a decade. No > idea why you'd think otherwise. I interpreted the original question as how many ports use _any_ textual prologue bits... with the idea of getting rid of TARGET_ASM_FUNCTION_PROLOGUE. In order to remove TARGET_ASM_FUNCTION_PROLOGUE and ensure that no port uses it for prologues in the future, the pa port would need to be changed to use another mechanism other than TARGET_ASM_FUNCTION_PROLOGUE to fprintf prologue bits. Would be nice to remove all traces of TARGET_ASM_FUNCTION_PROLOGUE. ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: ColdFire submission 2007-01-11 0:45 ` Mike Stump @ 2007-01-11 1:05 ` Jeffrey Law 0 siblings, 0 replies; 280+ messages in thread From: Jeffrey Law @ 2007-01-11 1:05 UTC (permalink / raw) To: Mike Stump; +Cc: Steven Bosscher, gcc-patches, Richard Sandiford On Wed, 2007-01-10 at 16:43 -0800, Mike Stump wrote: > On Jan 10, 2007, at 4:03 PM, Jeffrey Law wrote: > > PA uses RTL prologues/epilogues and has for about a decade. No > > idea why you'd think otherwise. > > I interpreted the original question as how many ports use _any_ > textual prologue bits... with the idea of getting rid of > TARGET_ASM_FUNCTION_PROLOGUE. Ah. I don't really care if ports are outputting text in TARGET_ASM_FUNCTION_PROLOGUE -- I do care if they are outputting *instructions* via that hook. What ports still output *instructions* via that hook? Jeff ^ permalink raw reply [flat|nested] 280+ messages in thread
* Re: ColdFire submission 2007-01-11 0:04 ` Jeffrey Law 2007-01-11 0:45 ` Mike Stump @ 2007-01-11 7:36 ` Eric Botcazou 1 sibling, 0 replies; 280+ messages in thread From: Eric Botcazou @ 2007-01-11 7:36 UTC (permalink / raw) To: law; +Cc: gcc-patches, Mike Stump, Steven Bosscher, Richard Sandiford > I'm pretty sure the SPARC uses RTL prologues/epilogues as well. Right, since the GCC4 series debuted. -- Eric Botcazou ^ permalink raw reply [flat|nested] 280+ messages in thread
end of thread, other threads:[~2007-04-20 17:34 UTC | newest] Thread overview: 280+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-01-10 10:30 ColdFire submission Richard Sandiford 2007-01-10 10:31 ` [ColdFire 1/63] Retabulate TARGET_CPU_CPP_BUILTINS Richard Sandiford 2007-01-10 10:33 ` [ColdFire 2/63] Use TUNE_* macros instead of TARGET_* macros Richard Sandiford 2007-01-10 10:34 ` [ColdFire 3/63] Add TUNE_68040_60 Richard Sandiford 2007-01-10 10:35 ` [ColdFire 4/63] TARGET_COLDFIRE_FPU vs. TARGET_CFV4E Richard Sandiford 2007-01-10 10:37 ` [ColdFire 5/63] Introduce TARGET_ISAB Richard Sandiford 2007-01-10 17:53 ` Jeffrey Law 2007-01-10 10:39 ` [ColdFire 6/63] Make gcc honour -m68010 Richard Sandiford 2007-01-10 10:45 ` [ColdFire 7/63] Default target selection and --with-cpu support Richard Sandiford 2007-01-10 10:46 ` [ColdFire 8/63] Share ASM_SPEC code between targets Richard Sandiford 2007-01-10 10:54 ` [ColdFire 9/63] Add -mcpu, -march, -mtune, and related options Richard Sandiford 2007-01-10 10:55 ` [ColdFire 10/63] Rename TARGET_68040_ONLY to TARGET_68040 Richard Sandiford 2007-01-10 10:57 ` [ColdFire 11/63] Treat mc680x0 macros as tuning-dependent macros Richard Sandiford 2007-01-10 10:58 ` [ColdFire 12/63] Add new predefined macros Richard Sandiford 2007-01-10 11:00 ` [ColdFire 13/63] Remove some RejectNegatives Richard Sandiford 2007-01-10 11:02 ` [ColdFire 14/63] Make "long double" the same as "double" on ColdFire Richard Sandiford 2007-01-10 11:05 ` [RTL, ColdFire 15/63] Avoid out-of-segment constants on uClinux Richard Sandiford 2007-01-10 11:10 ` [ColdFire 16/63] Bring *-uclinux configurations closer to *-linux-gnu Richard Sandiford 2007-01-10 11:13 ` [ColdFire 17/63] Assorted uClinux improvements Richard Sandiford 2007-01-10 11:15 ` [ColdFire 18/63] Configuration cleanups Richard Sandiford 2007-01-10 11:16 ` [ColdFire 19/63] Make MOTOROLA a numeric macro from the outset Richard Sandiford 2007-01-10 11:17 ` [ColdFire 20/63] Factor out soft-float library support Richard Sandiford 2007-01-10 11:19 ` [ColdFire 21/63] Add *_REGNO_P macros Richard Sandiford 2007-01-10 11:20 ` [ColdFire 22/63] Remove redundant PIC handling Richard Sandiford 2007-01-10 11:21 ` [ColdFire 23/63] Some assorted cleanups Richard Sandiford 2007-01-10 11:23 ` [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro Richard Sandiford 2007-01-10 11:24 ` [ColdFire 25/63] Define MODE_INDEX_REG_CLASS for m68k Richard Sandiford 2007-01-10 11:28 ` [ColdFire 26/63] Rework the call and jump handling Richard Sandiford 2007-01-10 11:32 ` [ColdFire 27/63] Addressing mode changes and fixes Richard Sandiford 2007-01-10 11:34 ` [middle-end, ColdFire 28/63] Change the canonical NaN representation Richard Sandiford 2007-01-10 11:35 ` [ColdFire 29/63] Fix a movdf bug Richard Sandiford 2007-01-10 11:38 ` [ColdFire 30/63] Fix rounding for ColdFire FPUs Richard Sandiford 2007-01-10 11:39 ` [ColdFire 31/63] Fix rounding problems in fpgnulib.c Richard Sandiford 2007-01-10 11:41 ` [ColdFire 32/63] Delete USE_RETURN_INSN Richard Sandiford 2007-01-10 11:42 ` [ColdFire 33/63] Force an epilogue when restoring FPU registers Richard Sandiford 2007-01-10 11:44 ` [ColdFire 34/63] Don't emit a nop after noreturn calls Richard Sandiford 2007-01-10 11:46 ` [RTL, ColdFire 35/63] Expose dual %d0/%a0 return value in RTL Richard Sandiford 2007-01-10 11:49 ` [ColdFire 36/63] Use RTL for prologues and epilogues Richard Sandiford 2007-01-10 11:50 ` [ColdFire 37/63] " Richard Sandiford 2007-01-10 11:51 ` [ColdFire 38/63] Clean up handling of integer moves Richard Sandiford 2007-01-10 11:53 ` [ColdFire 39/63] Fix mov3q handling Richard Sandiford 2007-01-10 11:55 ` [ColdFire 40/63] Add more movsf_cf_soft alternatives Richard Sandiford 2007-01-10 11:55 ` [ColdFire 41/63] Add support for the ff1 instruction Richard Sandiford 2007-01-10 11:56 ` [ColdFire 42/63] Add support for sibling calls Richard Sandiford 2007-01-10 11:57 ` [ColdFire 43/63] Use floating-point branches on ColdFire too Richard Sandiford 2007-01-10 11:58 ` [ColdFire 44/63] Remove unncessary saves and restores of %a5 Richard Sandiford 2007-01-10 12:00 ` [ColdFire 45/63] Set TARGET_ASM_FILE_START_APP_OFF to false for GNU/Linux Richard Sandiford 2007-01-10 12:01 ` [ColdFire 46/63] Add support for unwinding through signal handlers Richard Sandiford 2007-01-10 12:03 ` [ColdFire 47/63] Fix PR target/28181 Richard Sandiford 2007-01-10 12:04 ` [ColdFire 48/63] Fix the 'T' constraint Richard Sandiford 2007-01-10 12:06 ` [ColdFire 49/63] Save and restore the PIC register when using a constant pool Richard Sandiford 2007-01-10 12:07 ` [ColdFire 50/63] Save the PIC register for __builtin_eh_return Richard Sandiford 2007-01-10 12:08 ` [ColdFire 51/63] Don't use move.l CCs for SFmode comparisons Richard Sandiford 2007-01-10 12:09 ` [ColdFire 52/63] Don't use neg.l and negx.l on memory for ColdFire Richard Sandiford 2007-01-10 12:10 ` [ColdFire 53/63] Static chain fixes Richard Sandiford 2007-01-10 12:11 ` [ColdFire 54/63] Define PREFERRED_STACK_BOUNDARY Richard Sandiford 2007-01-10 12:13 ` [ColdFire 55/63] Add support for vcall_offset thunks Richard Sandiford 2007-01-10 12:15 ` [ColdFire 56/63] ColdFire multilibs and --with-arch Richard Sandiford 2007-01-10 12:17 ` [ColdFire 57/63] Automatically generate SYSROOT_SUFFIX on uClinux Richard Sandiford 2007-01-10 12:19 ` [ColdFire 58/63] XFAIL mul-subnormal-single-1 for ColdFire FPUs Richard Sandiford 2007-01-10 12:21 ` [ColdFire 59/63] compat-related testsuite fixes for uClinux Richard Sandiford 2007-01-10 12:22 ` [ColdFire 60/63] Tweak the memset() builtin tests Richard Sandiford 2007-01-10 12:24 ` [ColdFire 61/63] Fix vsnprintf() tests on uClibc Richard Sandiford 2007-01-10 12:25 ` [ColdFire 62/63] Tighten check in 20030125-1.x Richard Sandiford 2007-01-10 12:27 ` [ColdFire 63/63] libstdc++ testsuite fixes for uClibc Richard Sandiford 2007-01-10 14:52 ` Paolo Bonzini 2007-01-10 15:12 ` Richard Sandiford 2007-01-10 15:18 ` Paolo Bonzini 2007-01-10 17:31 ` Benjamin Kosnik 2007-01-16 18:14 ` [ColdFire 55/63] Add support for vcall_offset thunks Jeffrey Law 2007-01-10 18:00 ` [ColdFire 54/63] Define PREFERRED_STACK_BOUNDARY Jeffrey Law 2007-01-16 2:35 ` Roman Zippel 2007-01-16 17:08 ` Jeffrey Law 2007-01-10 19:19 ` [ColdFire 53/63] Static chain fixes Jeffrey Law 2007-01-10 21:32 ` Paul Brook 2007-01-10 21:48 ` Jeffrey Law 2007-01-10 21:54 ` Andrew Pinski 2007-01-10 22:06 ` Jeffrey Law 2007-01-10 22:09 ` Daniel Jacobowitz 2007-01-11 17:17 ` Jeffrey Law 2007-01-10 22:11 ` Richard Sandiford 2007-01-10 21:33 ` Richard Sandiford 2007-01-10 21:44 ` Richard Sandiford 2007-01-15 0:19 ` Gerald Pfeifer 2007-01-11 17:54 ` [ColdFire 52/63] Don't use neg.l and negx.l on memory for ColdFire Jeffrey Law 2007-01-10 18:48 ` [ColdFire 51/63] Don't use move.l CCs for SFmode comparisons Jeffrey Law 2007-01-10 19:20 ` [ColdFire 50/63] Save the PIC register for __builtin_eh_return Jeffrey Law 2007-01-22 17:52 ` Roman Zippel 2007-01-22 18:46 ` Richard Sandiford 2007-01-24 19:47 ` Jeffrey Law 2007-01-11 17:52 ` [ColdFire 49/63] Save and restore the PIC register when using a constant pool Jeffrey Law 2007-01-10 18:47 ` [ColdFire 48/63] Fix the 'T' constraint Jeffrey Law 2007-01-16 18:16 ` [ColdFire 47/63] Fix PR target/28181 Jeffrey Law 2007-01-16 1:38 ` [ColdFire 46/63] Add support for unwinding through signal handlers Roman Zippel 2007-01-16 5:20 ` Richard Sandiford 2007-01-22 17:16 ` Roman Zippel 2007-01-29 9:54 ` Richard Sandiford 2007-01-22 17:46 ` [m68k 2/2] unwind support for signal handler Roman Zippel 2007-01-28 9:04 ` Andreas Schwab 2007-01-22 17:49 ` [m68k 1/2] define DWARF_FRAME_RETURN_COLUMN Roman Zippel 2007-01-22 19:51 ` Richard Sandiford 2007-01-22 20:15 ` Andreas Schwab 2007-01-22 20:23 ` Richard Sandiford 2007-01-22 21:06 ` Andreas Schwab 2007-01-22 22:08 ` Richard Sandiford 2007-01-22 22:57 ` Andreas Schwab 2007-01-23 7:40 ` Richard Sandiford 2007-01-22 23:03 ` Roman Zippel 2007-01-23 7:55 ` Richard Sandiford 2007-01-23 11:52 ` Roman Zippel 2007-01-29 10:38 ` Richard Sandiford 2007-01-31 22:34 ` Andreas Schwab 2007-01-10 17:59 ` [ColdFire 45/63] Set TARGET_ASM_FILE_START_APP_OFF to false for GNU/Linux Jeffrey Law 2007-01-10 18:28 ` Andreas Schwab 2007-01-10 18:43 ` Jeffrey Law 2007-01-10 18:50 ` Andreas Schwab 2007-01-10 19:15 ` Jeffrey Law 2007-01-10 19:45 ` Andreas Schwab 2007-01-11 17:50 ` [ColdFire 44/63] Remove unncessary saves and restores of %a5 Jeffrey Law 2007-01-10 17:58 ` [ColdFire 43/63] Use floating-point branches on ColdFire too Jeffrey Law 2007-01-16 18:04 ` [ColdFire 42/63] Add support for sibling calls Jeffrey Law 2007-01-10 19:21 ` [ColdFire 41/63] Add support for the ff1 instruction Jeffrey Law 2007-01-10 18:46 ` [ColdFire 40/63] Add more movsf_cf_soft alternatives Jeffrey Law 2007-01-10 18:46 ` [ColdFire 39/63] Fix mov3q handling Jeffrey Law 2007-01-16 17:49 ` [ColdFire 38/63] Clean up handling of integer moves Jeffrey Law 2007-01-16 17:58 ` [ColdFire 37/63] Use RTL for prologues and epilogues Jeffrey Law 2007-01-10 23:06 ` [ColdFire 36/63] " Joseph S. Myers 2007-01-11 8:10 ` Richard Sandiford 2007-01-16 17:53 ` Jeffrey Law 2007-01-16 17:56 ` Richard Sandiford 2007-01-22 18:11 ` Roman Zippel 2007-01-22 20:07 ` Richard Sandiford 2007-01-23 1:05 ` Roman Zippel 2007-01-23 7:37 ` Richard Sandiford 2007-01-23 14:20 ` Roman Zippel 2007-01-23 16:12 ` Richard Sandiford 2007-01-23 16:50 ` Roman Zippel 2007-01-24 19:43 ` Jeffrey Law 2007-01-24 23:04 ` Roman Zippel 2007-01-24 23:26 ` Jeffrey Law 2007-01-29 10:23 ` Improve PARALLEL handling in dwarf2out_frame_debug_expr Richard Sandiford 2007-01-12 16:09 ` [RTL, ColdFire 35/63] Expose dual %d0/%a0 return value in RTL Ian Lance Taylor 2007-01-10 17:58 ` [ColdFire 34/63] Don't emit a nop after noreturn calls Jeffrey Law 2007-01-10 17:57 ` [ColdFire 33/63] Force an epilogue when restoring FPU registers Jeffrey Law 2007-01-10 17:57 ` [ColdFire 32/63] Delete USE_RETURN_INSN Jeffrey Law 2007-01-11 17:40 ` [ColdFire 31/63] Fix rounding problems in fpgnulib.c Jeffrey Law 2007-01-11 17:35 ` [ColdFire 30/63] Fix rounding for ColdFire FPUs Jeffrey Law 2007-01-10 18:44 ` [ColdFire 29/63] Fix a movdf bug Jeffrey Law 2007-01-11 5:32 ` [middle-end, ColdFire 28/63] Change the canonical NaN representation Roger Sayle 2007-01-11 17:30 ` [ColdFire 26/63] Rework the call and jump handling Jeffrey Law 2007-01-10 19:30 ` [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro Jeffrey Law 2007-01-10 21:28 ` Richard Sandiford 2007-01-16 21:42 ` Jeffrey Law 2007-01-17 5:36 ` Richard Sandiford 2007-01-17 6:07 ` Ian Lance Taylor 2007-01-17 6:30 ` Jeffrey Law 2007-01-17 13:57 ` Ian Lance Taylor 2007-01-17 16:49 ` Jeffrey Law 2007-01-17 16:57 ` Ian Lance Taylor 2007-01-17 17:27 ` Jeffrey Law 2007-01-17 18:09 ` Richard Sandiford 2007-01-17 18:26 ` Ian Lance Taylor 2007-01-18 19:37 ` Richard Sandiford 2007-02-09 15:16 ` Richard Sandiford 2007-02-12 17:38 ` Jeffrey Law 2007-02-12 23:09 ` Mark Mitchell 2007-02-12 23:27 ` Jeffrey Law 2007-02-13 18:01 ` Roman Zippel 2007-02-14 10:03 ` Richard Sandiford 2007-01-23 1:23 ` Roman Zippel 2007-01-23 8:03 ` Richard Sandiford 2007-01-23 16:47 ` Roman Zippel 2007-02-12 23:17 ` Jeffrey Law 2007-02-14 10:02 ` Richard Sandiford 2007-02-14 17:14 ` Jeffrey Law 2007-02-14 17:31 ` Ian Lance Taylor 2007-02-14 17:37 ` Richard Sandiford 2007-02-14 17:48 ` Ian Lance Taylor 2007-02-15 12:48 ` Bernd Schmidt 2007-02-23 9:58 ` Mark Mitchell 2007-02-27 0:30 ` Jeffrey Law 2007-02-27 18:55 ` Richard Sandiford 2007-02-27 19:02 ` Jeffrey Law 2007-02-27 20:44 ` Jeffrey Law 2007-02-27 21:44 ` Richard Sandiford 2007-02-27 22:34 ` Jeffrey Law 2007-02-28 0:57 ` Richard Sandiford 2007-02-28 3:37 ` Jeffrey Law 2007-02-28 16:17 ` Richard Sandiford 2007-02-28 19:47 ` Bernd Schmidt 2007-02-28 22:17 ` Jeffrey Law 2007-02-28 22:39 ` Jeffrey Law 2007-02-28 22:44 ` Richard Sandiford 2007-02-28 22:50 ` Mark Mitchell 2007-03-01 3:07 ` Roman Zippel 2007-03-01 5:11 ` Mark Mitchell 2007-02-28 22:58 ` Jeffrey Law 2007-02-28 0:17 ` Ian Lance Taylor 2007-02-28 0:21 ` Jeffrey Law 2007-03-01 3:14 ` Roman Zippel 2007-03-01 2:43 ` Roman Zippel 2007-02-27 20:22 ` Jeffrey Law 2007-02-27 20:25 ` Jeffrey Law 2007-02-14 19:10 ` Roman Zippel 2007-01-12 15:45 ` Ian Lance Taylor 2007-01-15 18:05 ` Jeffrey Law 2007-01-10 18:43 ` [ColdFire 23/63] Some assorted cleanups Jeffrey Law 2007-01-10 18:41 ` [ColdFire 22/63] Remove redundant PIC handling Jeffrey Law 2007-01-10 21:42 ` Richard Sandiford 2007-01-10 22:18 ` Jeffrey Law 2007-01-10 17:55 ` [ColdFire 21/63] Add *_REGNO_P macros Jeffrey Law 2007-01-15 18:51 ` Roman Zippel 2007-01-10 21:32 ` [ColdFire 20/63] Factor out soft-float library support Jeffrey Law 2007-01-10 21:51 ` Richard Sandiford 2007-01-10 22:08 ` Jeffrey Law 2007-01-18 19:26 ` [ColdFire 19/63] Make MOTOROLA a numeric macro from the outset Richard Sandiford 2007-01-10 18:51 ` [ColdFire 18/63] Configuration cleanups Jeffrey Law 2007-01-10 21:29 ` [ColdFire 17/63] Assorted uClinux improvements Jeffrey Law 2007-01-10 21:48 ` Richard Sandiford 2007-01-10 19:21 ` [ColdFire 16/63] Bring *-uclinux configurations closer to *-linux-gnu Christoph Hellwig 2007-01-10 22:03 ` Richard Sandiford 2007-01-10 22:13 ` Jeffrey Law 2007-01-12 12:08 ` Richard Sandiford 2007-01-16 17:45 ` Jeffrey Law 2007-01-10 21:24 ` Jeffrey Law 2007-01-11 4:53 ` [RTL, ColdFire 15/63] Avoid out-of-segment constants on uClinux Roger Sayle 2007-01-11 17:16 ` Jeffrey Law 2007-01-11 17:15 ` Jeffrey Law 2007-01-10 18:35 ` [ColdFire 14/63] Make "long double" the same as "double" on ColdFire Jeffrey Law 2007-01-11 10:51 ` Nathan Sidwell 2007-01-11 17:20 ` Jeffrey Law 2007-01-18 18:46 ` Richard Sandiford 2007-01-10 18:32 ` [ColdFire 13/63] Remove some RejectNegatives Jeffrey Law 2007-01-10 18:31 ` [ColdFire 12/63] Add new predefined macros Jeffrey Law 2007-01-10 18:28 ` [ColdFire 11/63] Treat mc680x0 macros as tuning-dependent macros Jeffrey Law 2007-01-10 18:27 ` [ColdFire 10/63] Rename TARGET_68040_ONLY to TARGET_68040 Jeffrey Law 2007-01-10 18:22 ` [ColdFire 9/63] Add -mcpu, -march, -mtune, and related options Jeffrey Law 2007-01-15 18:08 ` Roman Zippel 2007-01-15 22:40 ` Richard Sandiford 2007-01-16 2:43 ` Roman Zippel 2007-01-16 5:24 ` Richard Sandiford 2007-01-16 5:38 ` Richard Sandiford 2007-01-22 17:12 ` Roman Zippel 2007-04-12 1:53 ` Roman Zippel 2007-04-18 15:00 ` Richard Sandiford 2007-04-19 0:29 ` Roman Zippel 2007-04-19 7:08 ` Richard Sandiford 2007-04-19 7:13 ` Nathan Sidwell 2007-04-19 8:37 ` Andreas Schwab 2007-04-19 9:07 ` Richard Sandiford 2007-04-19 12:02 ` Joseph S. Myers 2007-04-19 12:08 ` Richard Sandiford 2007-04-19 13:22 ` Roman Zippel 2007-04-20 17:35 ` Ian Lance Taylor 2007-01-10 18:10 ` [ColdFire 8/63] Share ASM_SPEC code between targets Jeffrey Law 2007-01-10 18:09 ` [ColdFire 7/63] Default target selection and --with-cpu support Jeffrey Law 2007-01-10 18:11 ` Richard Sandiford 2007-01-10 18:07 ` [ColdFire 6/63] Make gcc honour -m68010 Jeffrey Law 2007-01-10 17:52 ` [ColdFire 4/63] TARGET_COLDFIRE_FPU vs. TARGET_CFV4E Jeffrey Law 2007-01-10 17:48 ` [ColdFire 3/63] Add TUNE_68040_60 Jeffrey Law 2007-01-10 17:47 ` [ColdFire 2/63] Use TUNE_* macros instead of TARGET_* macros Jeffrey Law 2007-01-15 17:16 ` Roman Zippel 2007-01-15 17:57 ` Andreas Schwab 2007-01-15 18:06 ` Roman Zippel 2007-01-15 18:32 ` Andreas Schwab 2007-01-10 17:47 ` [ColdFire 1/63] Retabulate TARGET_CPU_CPP_BUILTINS Jeffrey Law 2007-01-10 22:58 ` ColdFire submission Steven Bosscher 2007-01-10 23:13 ` Jeffrey Law 2007-01-10 23:36 ` Mike Stump 2007-01-10 23:41 ` Andrew Pinski 2007-01-10 23:47 ` Ian Lance Taylor 2007-01-10 23:47 ` Eric Christopher 2007-01-11 0:48 ` Mike Stump 2007-01-11 0:53 ` Eric Christopher 2007-01-11 8:09 ` Richard Sandiford 2007-01-11 14:48 ` Eric Christopher 2007-01-11 0:04 ` Jeffrey Law 2007-01-11 0:45 ` Mike Stump 2007-01-11 1:05 ` Jeffrey Law 2007-01-11 7:36 ` Eric Botcazou
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).