> [Differences from V3:
> . Formatting/style fixes:
> + Remove redundant braces.
> + Remove unneeded ATTRIBUTE_UNUSED.
> + Truncate too long lines.
> + Remove an odd line split.
> + Do not break after returns.
> + Use function_arg_info methods instead of auxiliary functions.
> + Fix indentation in cbranchdi4.
> . Use `sorry' and sorry_at to report lack of support for valid
> constructs.
> . Rename GR_REGS to GENERAL_REGS and exclude the pseudo arg_reg
> from the class.
As discussed on IRC, a simple NO_REGS/ALL_REGS split should be fine,
as for VAX. I don't think there's any reason in principle why
GENERAL_REGS mustn't include the arg pointer while ALL_REGS must.
The IRA move cost segfault looks like a simple oversight. It'd be
interesting to know why you only see the segfault with two classes --
is there a specific reason that it can only happen there? -- but
I don't think the segfault itself should be the reason for defining
the classes as above.
On one hand, it is sort of silly to use three register classes when two
classes can, in theory, do the job.
On the other, my lazyne^Wpreservation instinct impells me to be
conservative to avoid the possibility of uncovering more bugs...
However, I realize that accomodating bugs in the common code by
modifying backend's behavior is counter-productive in the long term, for
both the backend and the common code.
Ooook, I will be a good citizen and settle in using NO_REGS/ALL_REGS.
If it is supposed to be a valid configuration, then it should work
damnit :D
