This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Porting GCC to new architecture


Alexandre Tzannes <tzannes@cs.umd.edu> writes:

> I'm Alex Tzannes and I am porting GCC 4.0.2 to a new experimental parallel
> architecture. Here's one issue I don't know how to go about. The ISA of
> our machine is based on MIPS (so I made a copy of the MIPS back end and
> have been modifying that). One conceptual difference is that the machine
> can be either in serial mode or in parallel mode. The switch from serial
> to parallel happens with a 'spawn' instruction, and the swich from
> parallel to serial with a 'join' instruction. This is important because
> the ISA instructions that can be used in serial and in parallel mode are
> different !
> 
> For example let's say mvtg is an instruction that can only be used in
> 'serial mode'. I currently have a template in the back end (.md file) that
> generates that instruction when it is needed. The only thing I don't know
> how to check is that it is only generated in serial mode.
> 
> Instruction attributes do not seem like the solution because there seems
> to be no other way to set them besides in the RTL rules in the .md file
> (which is too late; I would want to read the information at that point).
> 
> Is there a way to annotate each RTL instruction and to check that during
> code generation ? Has a similar problem been solved in some other
> back-end?

I don't think I've ever seen a machine with these characteristics.

One way to make this work would be to use the OPTIMIZE_MODE_SWITCHING
support.  You would need to add an attribute for each instruction
indicating which mode it requires (presumably most instructions would
use the default value).  Then define MODE_NEEDED, etc., to indicate
the mode.  Use EMIT_MODE_SET to generate the spawn or join insn.  You
would have to make the spawn/join insn an UNSPEC_VOLATILE so that the
scheduler would not move insns across them.

Good luck.

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]