This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Can we speed up the gcc_target structure?
- From: "Zack Weinberg" <zack at codesourcery dot com>
- To: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- Cc: gcc at gcc dot gnu dot org
- Date: Mon, 19 Jan 2004 15:36:33 -0800
- Subject: Re: Can we speed up the gcc_target structure?
- References: <10401192127.AA02240@vlsi1.ultra.nyu.edu>
kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:
> #define PROMOTE_MODE(MODE,UNSIGNEDP,TYPE) \
> if (GET_MODE_CLASS (MODE) == MODE_INT \
> && GET_MODE_SIZE (MODE) < UNITS_PER_WORD) \
> { \
> if ((MODE) == SImode) \
> (UNSIGNEDP) = 0; \
> (MODE) = DImode; \
> }
> #define HARD_REGNO_NREGS(REGNO, MODE) \
> ((GET_MODE_SIZE (MODE) + UNITS_PER_WORD - 1) / UNITS_PER_WORD)
> #define HARD_REGNO_MODE_OK(REGNO, MODE) \
> ((REGNO) >= 32 && (REGNO) <= 62 \
> ? (MODE) == SFmode || (MODE) == DFmode || (MODE) == DImode \
> : 1)
> #define VECTOR_MODE_SUPPORTED_P(MODE) \
> (TARGET_MAX \
> && ((MODE) == V8QImode || (MODE) == V4HImode || (MODE) == V2SImode))
> #define MODES_TIEABLE_P(MODE1, MODE2) \
> (HARD_REGNO_MODE_OK (32, (MODE1)) \
> ? HARD_REGNO_MODE_OK (32, (MODE2)) \
> : 1)
> #define SECONDARY_MEMORY_NEEDED_MODE(MODE) \
> (GET_MODE_CLASS (MODE) == MODE_FLOAT ? (MODE) \
> : GET_MODE_SIZE (MODE) >= 4 ? (MODE) \
> : mode_for_size (BITS_PER_WORD, GET_MODE_CLASS (MODE), 0))
> #define CLASS_MAX_NREGS(CLASS, MODE) \
> ((GET_MODE_SIZE (MODE) + UNITS_PER_WORD - 1) / UNITS_PER_WORD)
> #define CANNOT_CHANGE_MODE_CLASS(FROM, TO, CLASS) \
> (GET_MODE_SIZE (FROM) != GET_MODE_SIZE (TO) \
> ? reg_classes_intersect_p (FLOAT_REGS, CLASS) : 0)
> #define REGISTER_MOVE_COST(MODE, CLASS1, CLASS2) \
> (((CLASS1) == FLOAT_REGS) == ((CLASS2) == FLOAT_REGS) \
> ? 2 \
> : TARGET_FIX ? 3 : 4+2*alpha_memory_latency)
> #define MEMORY_MOVE_COST(MODE,CLASS,IN) (2*alpha_memory_latency)
...
Whether by accident or intention you picked a lot of stuff having to
do with register classes, and I'm going to turn around and say that
this is a place ripe for redesign. Wasn't Michael Matz just saying
that regclass.c needed a major rework anyway, or the new register
allocator would never be able to replace the old? I don't know what
his design looks like, or even if he has one yet, but surely there is
a simpler way to structure this, that doesn't involve lots of little
tiny macros.
zw