[M16C] 20 bit access

[DJ Delorie]

Some general comments...

> The pointer access will use the [A0A1] addressing mode.=20

Are you defaulting to assuming 20 bit mode?  Because that's a lot
slower.

Also, be careful about the difference between "a pointer which is IN
far memory" and "a pointer which points TO far memory".  I think you
need to attach the near/far attribute to the type, not the variable,
to get this right.

> Next stage: The constraints (Sc)

Why "c"?  For all the others, the letter has some semantic meaning.
You used "Sn" for near, why not "Sf" for far?

Also, the predicates should check for the actual near/far attributes,
not just "it can fit".

> We are not yet sure of implementing the [A0A1] addressing mode as
> this mode requires pointer greater then 16 bit. Currently M16C
> target supports only 16 bit pointer. Any help in implementing this
> mode will be highly appreciated.

It supports bigger pointers, but not by default.  I've had some
success creating SI-mode pointers in order to set up reset vectors and
such, but that was on m32c.  Here's how I create SI-mode function
pointers in m32c for interrupt tables:

typedef void (*ifunc)() __attribute__((mode(SI)));

> +  if (memcmp (str, "Sc", 2) == 0)
> +    {
> +      rtx r;
> +      if (RTX_IS ("mr"))
> +        {
> +          if (REGNO (patternr[1]) == A0_REGNO
> +              && (GET_MODE_SIZE (GET_MODE (value)) == 3
> +              || GET_MODE_SIZE (GET_MODE (value)) == 4))
> +            return 1;
> +          else
> +            return 0;
> +        }
> +      else if (RTX_IS ("m+ri"))
> +        {
> +          if (REGNO (patternr[2]) == A0_REGNO
> +              && (INTVAL (patternr[2]) > 0)
> +              && (INTVAL (patternr[2]) + INTVAL (patternr[3]) > 0xffff))
> +        return 1;
> +      else
> +        return 0;
> +        }
> +      else
> +        return 0;
> +    }

When writing patterns for specific cases that don't match the generic pattern,
it's best to be specific in the predicate, not the constraint.  In your case:

> +(define_insn "movqi_op1"
> +  [(set (match_operand:QI 0 "m32c_nonimmediate_operand" "=Rqi*Rmm")
> +        (match_operand:QI 1 "mem3_operand" "Sn"))]

This has the same pattern as the generic movqi, so you should make the
constraints more specific and just add them to the generic movqi as
one of the alternatives.

> +static tree
> +far_data_handler (tree * node, tree name,
> +                  tree args ATTRIBUTE_UNUSED,
> +                  int flags ATTRIBUTE_UNUSED, bool * no_add_attrs)
> +{
> +  if (!TARGET_R8C && !TARGET_M16C)
> +    {
> +      warning (OPT_Wattributes,
> +               "%qs attribute is supported only for R8C and M16C targets, attribute ignored",
> +	       IDENTIFIER_POINTER (name));

Why?  There are m16c chips with all the memory under 64k, and r8c
chips with some of the memory above 64k.

I know I said you could get by without it, but I don't think we need
to deny it to the user if they have a legitimate reason for it.

> +/* Modified for M16C-20bit*/
>  (define_insn "movhi_op"

I don't see anything other than whitespace changes.

> +; M16C-20bit Access
> +; TRUE for memory values that satisfy ABS mode

If you're using separate patterns for the 20-bit accesses, the
predicates should check for the near/far attributes as well, else
insns that need the generic patterns will match the specific one too
often.

> +(define_predicate "mem1_operand"
> +(define_predicate "mem2_operand"
> +(define_predicate "mem3_operand"

Please use meaningful names, and prefix them with "m32c_" to keep them
namespace-clean.  Like, "m32c_20bA0A1_operand".


> +MULTILIB_OPTIONS = mcpu=r8c/mcpu=m32cm
> +MULTILIB_DIRNAMES = r8c m32cm
> +MULTILIB_MATCHES = mcpu?m32cm=mcpu?m32c

For compatibility, I think the default should be r8c, since that what
the compiler's current default is.

Also, if we're adding an m16c multilib, this would be a good time to
make it default to 16 bit data/code alignment, since it's a 16 bit bus
internally, unlike the r8c.