Use define_constraint for MIPS

[Richard Sandiford]

Zack Weinberg <zackw@panix.com> writes:
> On Thu, Mar 09, 2006 at 06:35:04PM +0000, Richard Sandiford wrote:
>> > * Speaking of which, when I did i386 I put the constraints at the end
>> >   of the existing predicates.md.  I don't have a strong opinion on which
>> >   style is better, but we should probably be consistent across architectures.
>> 
>> Yeah, I noticed that, and deliberately didn't follow it.  I found it
>> a bit confusing to have non-predicate definitions in a file called
>> "predicates.md".  (When you're new to gcc, the difference between
>> predicates and constraints can be a bit confusing.  Having them both
>> lumped in a file called "predicates.md" might make things even worse.)
>
> Sounds like good reasons to me.  Should we then split the i386 constraints
> to a separate file, you think?

Yeah, I suppose that would keep the consistency you mention.

>> > * I see a lot of constraints whose docstrings are just '@internal' with
>> >   no further explanation.   Is there any hope of getting real documentation
>> >   for those?
>> 
>> All but one were register constraints.  I don't know if you're asking
>> whether they should lose the "@internal" or whether they should have
>> some documentation besides "@internal".
>
> The latter.  Note that my plan is to have "@internal" constraints show
> up in the internals manual, but not the user manual.

Ah, OK.  To be honest, I don't see the point of having _any_ machine-specific
constraints in the internals manual once a machine have been converted to
use define_constraint.  I suppose one of the reasons for having them in
the old days was because the definitions were split over so many macros,
and having a centralised list in the internals manual might have been
useful.  But now we can simply say "Each machine can also define extra
constraints in its constraints.md file.  See ... for the format of the
constraint definitions."  So...

>> In the former case: no, I think
>> they should remain internal.  I don't want things like 'e' to become
>> part of the documented interface.  In the latter case: these sorts of
>> internal register constraints are essentially self-documenting.  The
>> definition tells you which class is selected, and documentation about
>> what that class actually means can be found above the class definition.
>> I dislike cut-&-pasting the comment and then requiring that the two
>> copies be synchronised by hand.  It's like what happens with the
>> boiler-plate macro comments in the config header files: it's too
>> easy to forget to update them all when you update tm.texi.
>> 
>> The exception was 'Q', which maps directly to a predicate.
>> Similar comments apply there too.
>
> I'm not entirely comfortable with this, but I don't have a good answer
> to your concerns either.  (The point of this exercise is after all to
> -reduce- the number of copies of the information...) Perhaps if you had
> a suggestion for how to treat just-"@internal" constraints in the
> internals manual, so that it at least has a complete list of all the
> names in use ... ?

...would that be OK?

Richard