RFD: constraint letter suffixes

RFD: constraint letter suffixes

[Joern Rennecke]

Constraint letters are often in short supply, be it for register
classes, integer constants or extra constraints.
We can overcome these limitations by allowing suffixes to distinguish
different variants.  IMHO the most obvious suffix would be to append
a single digit.   This will work if matching constraints are generally
named first in any list of constraints with equal visibility within an
alternative.  Of course, every time we make a new arbitrary limit, we
run the risk of exceeding that limit in the future.  So if we are
putting a mechanism in place to handle constraint letter suffixes,
we might as well allow multi-letter/digit suffixes.

So I propose the following new target macros:

CONSTRAINT_LETTER_SUFFIX_LEN(C)
 For constraint letter C, give the length of the suffix.  defaults.h
 provides a default definition as 0 for all letters.
 This macro is used when iterating over a constraint list to correctly
 advance to the next constraint.  Note that the default definition will
 provide backwards compatibility with ports that put matching constraint
 digits immediately after constraint letters.

CONST_OK_FOR_LETTER_AND_SUFFIX_P(VALUE, C, STR)
 For constraint letter C and the suffix at the start of STR (STR is the
 rest of the constraints string after C), return 1 if VALUE is in the
 appropriate range, 0 otherwise.  If CONST_OK_DOR_LETTER_P is defined,
 defaults.h provides a default definition based on the latter macro.
 
Likewise for:
REG_CLASS_FROM_LETTER_AND_SUFFIX(C, STR)
EXTRA_CONSTRAINT_WITH_SUFFIX(VALUE, C, STR)

-- 
--------------------------
SuperH (UK) Ltd.
2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
T:+44 1454 462330

Re: RFD: constraint letter suffixes

[Joern Rennecke]

Joern Rennecke wrote:
> 
> Constraint letters are often in short supply, be it for register
> classes, integer constants or extra constraints.
> We can overcome these limitations by allowing suffixes to distinguish
> different variants.  IMHO the most obvious suffix would be to append
> a single digit.   This will work if matching constraints are generally
> named first in any list of constraints with equal visibility within an
> alternative.  Of course, every time we make a new arbitrary limit, we
> run the risk of exceeding that limit in the future.  So if we are
> putting a mechanism in place to handle constraint letter suffixes,
> we might as well allow multi-letter/digit suffixes.
> 
> So I propose the following new target macros:
> 
> CONSTRAINT_LETTER_SUFFIX_LEN(C)
>  For constraint letter C, give the length of the suffix.  defaults.h
>  provides a default definition as 0 for all letters.
>  This macro is used when iterating over a constraint list to correctly
>  advance to the next constraint.  Note that the default definition will
>  provide backwards compatibility with ports that put matching constraint
>  digits immediately after constraint letters.
> 
> CONST_OK_FOR_LETTER_AND_SUFFIX_P(VALUE, C, STR)
>  For constraint letter C and the suffix at the start of STR (STR is the
>  rest of the constraints string after C), return 1 if VALUE is in the
>  appropriate range, 0 otherwise.  If CONST_OK_DOR_LETTER_P is defined,
>  defaults.h provides a default definition based on the latter macro.
> 
> Likewise for:
> REG_CLASS_FROM_LETTER_AND_SUFFIX(C, STR)
> EXTRA_CONSTRAINT_WITH_SUFFIX(VALUE, C, STR)

Hmm, maybe it is simpler to just give the length of the whole constraint,
and pass the whole constraint, too.  I.e:

CONSTRAINT_LEN(C, STR)
 For the constraint STR starting with character C, give the length.
 When actually processing a matching constraint, the this length is
 ignored.  (So you don't have to figure out how long a number is in
 this macro, but you should return a number between 1 and the actual
 length of the number so that searching for specific non-matching
 constraints will work).
 defaults.h provides a default definition as 1.
 This macro is used when iterating over a constraint list to correctly
 advance to the next constraint.  Note that the default definition will
 provide backwards compatibility with ports that put matching constraint
 digits immediately after constraint letters.  (As well as for all other
 ports, of course.)
 It is invalid for a machine description to include a comma or NUL in a
 constraint - this can be checked in genoutput.c

CONST_OK_FOR_CONSTRAINT (C, STR)
 For constraint STR starting with C, return 1 if VALUE is in the
 appropriate range, 0 otherwise.  If CONST_OK_FOR_LETTER_P is defined,
 defaults.h provides a default definition based on the latter macro.

Likewise for:
REG_CLASS_FROM_CONSTRAINT
EXTRA_CONSTRAINT_STR (it would be consistent to call it EXTRA_CONSTRAINT,
 but that would be a backwards compatibility nigtmare)

	
-- 
--------------------------
SuperH (UK) Ltd.
2410 Aztec West / Almondsbury / BRISTOL / BS32 4QX
T:+44 1454 465658

Re: RFD: constraint letter suffixes

[Joern Rennecke]

EXTRA_MEMORY_CONSTRAINT is defined only by one port, and
EXTRA_ADDRESS_CONSTRAINT by none, so I suppose adding another
parameter to these macros isn't too much of a switch burden.
-- 
--------------------------
SuperH (UK) Ltd.
2410 Aztec West / Almondsbury / BRISTOL / BS32 4QX
T:+44 1454 465658

Re: RFD: constraint letter suffixes

[Ulrich Weigand]

Joern Rennecke wrote:

>EXTRA_MEMORY_CONSTRAINT is defined only by one port, and
>EXTRA_ADDRESS_CONSTRAINT by none, so I suppose adding another
>parameter to these macros isn't too much of a switch burden.

I have a patch that will introduce EXTRA_ADDRESS_CONSTRAINT
to the s390 port as well; I had been holding this until the
3.4 development was opened.

In any case, I don't mind another parameter there, in particular
if I get more constraint letters from it ;-)

Will it be possible to have more different integer constant
constraints with your patch?  This would be helpful for s390 ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de

Re: RFD: constraint letter suffixes

[Joern Rennecke]

Ulrich Weigand wrote:
> 
> Joern Rennecke wrote:
> 
> >EXTRA_MEMORY_CONSTRAINT is defined only by one port, and
> >EXTRA_ADDRESS_CONSTRAINT by none, so I suppose adding another
> >parameter to these macros isn't too much of a switch burden.
> 
> I have a patch that will introduce EXTRA_ADDRESS_CONSTRAINT
> to the s390 port as well; I had been holding this until the
> 3.4 development was opened.
> 
> In any case, I don't mind another parameter there, in particular
> if I get more constraint letters from it ;-)

The numbers of the letters will stay the same, but you will be able
to use one letter for multiple different constraints by using
a suffix, e.g. L0, L1, L2.
> Will it be possible to have more different integer constant
> constraints with your patch?  This would be helpful for s390 ...

Yes, this was actually the motivation of this patch.  The SH also
needs more different integer constraints.
	
-- 
--------------------------
SuperH (UK) Ltd.
2410 Aztec West / Almondsbury / BRISTOL / BS32 4QX
T:+44 1454 465658

Re: RFD: constraint letter suffixes

[Joern Rennecke]

P.S.: While I am at rewriting all that code, I think I might as well
replace uses of REG_CLASS_FROM_LETTER (*str) with
REG_CLASS_FROM_CONSTRAINT (*str, str) ; we can leave the definition
of the latter as hard-coded to use the former now, but if we ever need
more register class specifications (or just want to make the choice a bit
more intuitive, e.g. if you have ten flavours of slightly different arcane
floating point register classes (leaving out certain registers, and
union / complement classes...), why should you scavange for disjoint
unused letters?), it'll be a simple change in defaults.h to support
overriding this macro.

-- 
--------------------------
SuperH (UK) Ltd.
2410 Aztec West / Almondsbury / BRISTOL / BS32 4QX
T:+44 1454 465658

Re: RFD: constraint letter suffixes

[Ulrich Weigand]

Joern Rennecke wrote:

> P.S.: While I am at rewriting all that code, I think I might as well
> replace uses of REG_CLASS_FROM_LETTER (*str) with
> REG_CLASS_FROM_CONSTRAINT (*str, str) ;

As a side note, I was wondering why the new-style macros all get
both a letter and string (where the letter presumably is always
guaranteed to be equal to the first character of the string?).

What's the reason for this redundancy?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de

Re: RFD: constraint letter suffixes

[Joern Rennecke]

Ulrich Weigand wrote:
> 
> Joern Rennecke wrote:
> 
> > P.S.: While I am at rewriting all that code, I think I might as well
> > replace uses of REG_CLASS_FROM_LETTER (*str) with
> > REG_CLASS_FROM_CONSTRAINT (*str, str) ;
> 
> As a side note, I was wondering why the new-style macros all get
> both a letter and string (where the letter presumably is always
> guaranteed to be equal to the first character of the string?).

Yes.
	
> What's the reason for this redundancy?

If the macro definition needs only or mostly the first letter, the code
can be somewhat simpler, thus making the compiler faster.  I haven't
benchmarked the impact, but then this might be hard to do in a meanigful
way, as it could vary considerably between targets and input source.
Keeping the interface essentially the same for targets that don't need
the extra functionality seemed to be the safest option.

It also makes it easy to use only the new macros without needing to
dereference if all you want is the first letter.
	
-- 
--------------------------
SuperH (UK) Ltd.
2410 Aztec West / Almondsbury / BRISTOL / BS32 4QX
T:+44 1454 465658

Re: RFD: constraint letter suffixes

[Joern Rennecke]

Ulrich Weigand wrote:
> Will it be possible to have more different integer constant
> constraints with your patch?  This would be helpful for s390 ...

I've posted the patch now here:

http://gcc.gnu.org/ml/gcc-patches/2003-01/msg00367.html
	
-- 
--------------------------
SuperH (UK) Ltd.
2410 Aztec West / Almondsbury / BRISTOL / BS32 4QX
T:+44 1454 465658