This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
RFC: machine specific alternative cost modifier
- From: Joern Rennecke <joernr at arc dot com>
- To: gcc at gcc dot gnu dot org
- Date: Fri, 17 Oct 2008 16:01:09 +0100
- Subject: RFC: machine specific alternative cost modifier
ARCompact has three-address instructions, but it has a number of
shorter two-address instruction codes.
When optimizing or speed, I think it would generally be best to
choose the three-address alternatives for input reloads, since this
allows more reload inheritance. OTOH, when optimizing for size, the
two-address alternatives are probably better.
I would like to define a machine-specific contraint modifier that
adjustes reject in find_reloads similarly as '?' and '!' do, but
has the actual amount defined in target code. I.e. for the size/speed
tradeoff explained above, I would make the reject adjustment zero when
optimizing for size, something nonzero like - e.g. six - when optimizing
for speed, and then use this constraint modifier to adjust the
two-address alternatives (which come first so that they will
dominate when there is an exact match).
Would such a patch acceptable?
What do you think about which characters to use for the first
constraint modifier character; should I use a letter like ordinary
constraints, or should I rather grab one of the currently unused
'punctuation' (i.e. non-alphanumeric, printable) characters?