Re: RFC: machine specific alternative cost modifier

[Ian Lance Taylor <iant at google dot com>]

Joern Rennecke <joernr@arc.com> writes:

> 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?

I think you could achieve the same result by writing multiple
define_insn patterns and using the instruction predicate.

I'm not strongly opposed to your suggestion, but before adopting it
I'd prefer to see some indication that at least one other port would
use it.

Ian