This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: define_constraints patch, revised
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