Re: gcc-in-cxx update / multi-targeted gcc

[Ian Lance Taylor <iant at google dot com>]

Joern Rennecke <amylaar@spamcop.net> writes:

> I've found some issues with gcc-in-cxx both specific to these
> targets, and specific to (parts of) compiler passes that are
> only compiled for a subset of all tagets, which include one or
> more of the above mentioned three.

I'd be happy to see and approve your patches.  Several people have made
changes to the gcc-in-cxx branch.  Just send them to gcc-patches as
usual with [gcc-in-cxx] in the Subject.

> However, I have already noticed that you are pushing the target vector
> in a nonsentical direction: you are using target-specific enums, like
> enum reg_class .  We can't have the target vector refer to these enums,
> since they are different for each target.

I'm not sure why you are singling me out.  I only added one use of enum
reg_class to the target vector; there were already two other uses of
enum reg_class, and many uses of enum machine_mode.  If we decide that a
multi-targeted gcc is a goal we want to support, it's certainly fine
with me to change those enums to int and add casts where appropriate.
(I'm not personally convinced that a multi-targeted gcc is particularly
useful, though I don't object if there is a general desire to support
it.)

> Something which I miss in C++ is a way to declare that a function uses
> an integral type to pass an enum value (in arguments or return value),
> and then at function definition time only check that the integral type
> is sufficently large to hold the enum, and then for type checking purposes
> treat the parameter / return value as if it had been declared as this enum.
> FWIW, the target vector is more an obstruction than a help to make gcc
> multi-targeted.  macros that change the way an rtl optimization pass
> work just fine - I then end up with different versions of the rtl
> optimization pass in different namespaces, which are accessed by pass
> lists which are initialized by code living in the same name space.

It is perhaps worth noting that the natural way to handle the target
vector in C++ is to make a Target class with a set of virtual methods.
Then methods like eh_return_filter_mode would use a covariant return
type in specific implementations.  Where the mode is a parameter it
would still have to be changed to int.

> My plan (I haven't started implementing this yet) for enum machine_mode
> is to have each number denote a mode with the same number of bits and
> mode class on all configured targets on which they denote a usable mode.
> I'm not sure yet if it will be helpful to diable modes not usable on a
> target by making them MODE_RANDOM.

I suspect that would indeed be the best approach for machine_mode in a
multi-targeted gcc.

> What are your thoughts on using gcc extensions for gcc-in-cxx ?
> We can work around the enum issues by liberally sprinkling casts all over
> the code, but we are really working against the language there.
> We could try to implement en extension to describe integral types used
> to pass enums, where the enums only need an unqualified name match.
>
> E.g. we could have:
> typedef int enum_reg_class __attribute__ ((enum (reg_class));
>
> and have that be compatible with mips::enum reg_class for a
> funtion definition in the mips namespace, with spu::enum reg_class
> for a function definition in the spu namespace, and with plain
> enum reg_class anywhere.

I think you need to take a step back.  What is a natural way to
represent a register class in the machine independent code when writing
in C++?  I don't think it is to use an enum type.  A register class is
basically an object which implements methods like
    bool is_regno_in_class(unsigned int);
    HARD_REG_SET registers_in_class();
    bool equals(Reg_class);
    bool is_superset_of(Reg_class);
    bool is_subset_of(Reg_classS);
Obviously that is a long way off in gcc.  But I don't see any need to
add new features to the C++ frontend to support a style of programming
which is inappropriate for C++.  We can just convert between int and the
enum types for now.

> Another enum problem is enum attr_cpu / enum processor_type in the
> sh machine description.  We need a variable  (sh_cpu aka sh_cpu_attr)
> with this type to be visible inside the attributes generated by genattrtab.
> Choices to solve these kind of problems would be:
> - introduce another target header which is guaranteed to be included only
>   after enum definitions from generator files are in effect.
> - allow the gcc extension of statement expressions to be used in
>   target descriptions, so that a macro could provide an extern declaration
>   of a variable before using its value.

A simple approach would be to have a way to say that the enum values for
an attribute were already declared.  Then instead of listing the values
in the define_attr, we would just have a standard mapping from constants
of the attribute to the enum names to use.  We would have less error
checking in the generator programs, but the errors would be caught when
the generated code was compiled.

Ian