This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]