On 03/10/2011 04:47 PM, Nathan Froyd wrote:
[moving to gcc@ to get input from a wider audience]
On Thu, Mar 10, 2011 at 06:47:20AM +0100, Hans-Peter Nilsson wrote:
From: Nathan Froyd<froy...@codesourcery.com>
On Thu, Mar 10, 2011 at 04:02:27AM +0100, Hans-Peter Nilsson wrote:
PS. If you really feel for it, I won't stop you converting MMIX. :)
Heh. I looked at doing MMIX; I think the only tricky thing might be
dealing with the 'U' constraint.
Hm. Speaking of macros with semantics different depending on
REG_OK_STRICT being defined (should be just register and address
constraints), how do you do that in constraints.md? I looked
around but haven't found the answer. I guess you've bumped into
that problem a few times now, or some converted target will find
out the hard way?
(Please CC any reply to gcc@)
I haven't ran into that problem; all the targets I've converted to
constraints.md haven't had constraints that changed based on strictness.
I think the right thing to do is depend on
reload_{in_progress,completed}
(cf. rs6000/predicates.md:volatile_memory_operand), but I freely admit
this is a part of the compiler that I'm not familiar with.
In fact, I think the only targets remaining for constraints.md are
(besides h8300, which I haven't received an ack on yet) are:
- mmix ('U' dependent on strictness);
- cris (all interesting constraints based on strictness, I think);
- m32c (tedious to convert due to m32c-specific encode_pattern).
so knowing how to deal with strictness would help a great deal.
I guess you can leave everything in the target header and use a macro.
This basically depends on the constraint checks being always in a header
(tm_constrs.h).
Paolo
