Re: define_constraints patch, revised

[Zack Weinberg <zackw at panix dot com>]

On Wed, Feb 22, 2006 at 12:07:41AM +0100, Bernd Schmidt wrote:
> >>Can't we extend the syntax for define_*_constraint to add an "internal" 
> >>flag somehow?  Sounds like there's a useful feature waiting to be 
> >>discovered here.
> >
> >Well, I'm not sure what other syntax is feasible (suggestions
> >welcome), and I don't see why whatever non-manual use we found
> >couldn't just look at the docstring.
> 
> An optional element at the end, so that you add "internal" at the end of 
> the definition to make an internal constraint?  We have that ability in 
> rtl parsing, don't we?

We do, but is this really better than "@internal" at the beginning of the
docstring?

> >I'm not sure I understand the question.  Mangling only applies to
> >the enumeration constants for *individual* constraint names, not to
> >operand constraint strings.  If you mean "P4gt>" to be an individual name,
> >well, it would be mangled to CONSTRAINT__P4gtgt. "P4gtgt" would be
> >CONSTRAINT_P4gtgt, with one fewer underscore.
> 
> What about "P4>>" vs "P4gt>" and "P4>gt"?

Ugh, yes, those would all mangle to the same thing.  I'll redo this
with the __, _gt, _lt pattern you suggested.

> This is one area where I kind of like our coding standards, as I don't 
> like to keep things lined up when changing them.  (An area where I'm 
> always tempted to ignore the coding standards is one comment per 
> function, but you might want to add a few to the larger ones...)

Eh, I don't care that much, so I'll redo it your way.

> >Note that even if I did break up constraint_satisfied_p into
> >a set of satisfies_constraint_XXX functions, we would need to keep
> >constraint_satisfied_p and all the other functions that take an
> >enum constraint_num, because they're necessary to implement the old
> >interface that MI code still uses.  I'm up for cleaning up that
> >interface, but only after all ports use the new framework.
> 
> I'm ok with that, but it'll make us change a lot of port-specific files 
> twice if we go with per-constraint functions in the end.  Might be less 
> work to do it upfront.

Yeah, I'm not objecting to the per-constraint functions.  I think I shall
not generate them for register constraints, though, and retract support
for them in satisfies_constraint_p (I had not realized when I originally
added that that it would mean reg_fits_class_p would be called twice for
every register constraint that fails to match).

zw