* 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
* [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 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 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 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 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 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 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 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 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
* 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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: [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 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 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 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 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 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 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 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 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 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: [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: [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 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 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: [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 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 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 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 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 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 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 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 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 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 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 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 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 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: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 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 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 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 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 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 ` Eric Christopher
` (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 ` Eric Christopher
2007-01-11 0:48 ` Mike Stump
2007-01-10 23:47 ` Ian Lance Taylor
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:36 ` Mike Stump
2007-01-10 23:41 ` Andrew Pinski
2007-01-10 23:47 ` Eric Christopher
@ 2007-01-10 23:47 ` Ian Lance Taylor
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
` (2 preceding siblings ...)
2007-01-10 23:47 ` Ian Lance Taylor
@ 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-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: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: [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: [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 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
* 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 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 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 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: [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: [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: [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 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 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: [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 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 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 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 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 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: [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 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 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 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: [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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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: [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: [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 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: [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: [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 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
* [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
* [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: [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 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 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: [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: [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: [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 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: [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: [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: [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: [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 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: [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: [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: [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: [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: [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 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 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
* 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
* 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
* 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: [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: [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-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-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-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-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-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: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-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-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-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 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-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: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-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-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-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-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: [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
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 ` 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-10 23:47 ` Ian Lance Taylor
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).