From: "Zack Weinberg" <zack@codesourcery.com>
To: kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
Cc: gcc@gcc.gnu.org
Subject: Re: Can we speed up the gcc_target structure?
Date: Mon, 19 Jan 2004 23:36:00 -0000 [thread overview]
Message-ID: <87ad4jpl32.fsf@egil.codesourcery.com> (raw)
In-Reply-To: <10401192127.AA02240@vlsi1.ultra.nyu.edu> (Richard Kenner's message of "Mon, 19 Jan 04 16:27:17 EST")
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
next prev parent reply other threads:[~2004-01-19 23:36 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-19 21:25 Richard Kenner
2004-01-19 23:36 ` Zack Weinberg [this message]
-- strict thread matches above, loose matches on Subject: below --
2004-01-19 23:48 Richard Kenner
2004-01-19 23:42 Richard Kenner
2004-01-19 23:46 ` Zack Weinberg
2004-01-19 19:05 Richard Kenner
2004-01-19 21:15 ` Zack Weinberg
2004-01-19 18:18 Richard Kenner
2004-01-19 18:26 ` Zack Weinberg
2004-01-19 11:51 Richard Kenner
2004-01-19 12:01 ` Richard Guenther
2004-01-19 20:02 ` Richard Henderson
2004-01-19 14:16 ` Robert Dewar
2004-01-19 18:03 ` Zack Weinberg
2004-01-18 22:18 Chris Lattner
2004-01-18 22:33 ` Jan Hubicka
2004-01-18 22:40 ` Chris Lattner
2004-01-18 22:48 ` Jan Hubicka
2004-01-18 22:50 ` Chris Lattner
2004-01-18 23:27 ` Jan Hubicka
2004-01-18 23:34 ` Jakub Jelinek
2004-01-19 1:36 ` Chris Lattner
2004-01-18 22:42 ` Joseph S. Myers
2004-01-18 22:44 ` Chris Lattner
2004-01-18 22:36 ` Richard Henderson
2004-01-18 22:42 ` Chris Lattner
2004-01-18 8:37 Ian Lance Taylor
2004-01-18 9:03 ` Zack Weinberg
2004-01-18 14:09 ` Ian Lance Taylor
2004-01-18 22:25 ` Zack Weinberg
2004-01-19 0:53 ` Ian Lance Taylor
2004-01-19 1:18 ` Geoff Keating
2004-01-18 11:30 ` Joseph S. Myers
2004-01-18 13:58 ` Kaveh R. Ghazi
2004-01-18 19:54 ` Ian Lance Taylor
2004-01-18 20:10 ` Richard Henderson
2004-01-18 20:17 ` Ian Lance Taylor
2004-01-18 21:14 ` Joseph S. Myers
2004-01-18 22:05 ` Richard Henderson
2004-01-18 22:22 ` Jan Hubicka
2004-01-18 22:37 ` Richard Henderson
2004-01-19 19:33 ` DJ Delorie
2004-01-19 20:41 ` Richard Henderson
2004-01-19 1:12 ` Geoff Keating
2004-01-19 13:51 ` Ian Lance Taylor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ad4jpl32.fsf@egil.codesourcery.com \
--to=zack@codesourcery.com \
--cc=gcc@gcc.gnu.org \
--cc=kenner@vlsi1.ultra.nyu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).