This is the mail archive of the 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]

ideas for modeling a condition-code FIFO?

I'm working on a GCC port to a machine that has a condition-code FIFO
with 7 elements.  Every cycle, the adder functional unit shifts the
FIFO down one slot, then sets C,N,V at the front.  Branch and
conditional-move insns can name a condition-code set by its offset
from the front of the FIFO.  E.g.:

        insn-0: CC[0..5] -> CC[1..6]; adder sets CC[0]
        insn-1: CC[0..5] -> CC[1..6]; adder sets CC[0]
        insn-2: CC[0..5] -> CC[1..6]; adder sets CC[0]
        insn-3: can refer to insn-0's condition codes as CC[2]

The Z condition must be set explicitly with a zero-detect operation.
(This machine is VLIW, so a zero-detect will be in the same bundle
as an adder op, and its result will go in CC[0] along with C,N,V for
the adder's op).

I wonder how to model this in the GCC machine description.  Are there
GCC ports to architectures that have a similar feature?

One idea is to generate new pseudos for a CC register bound to every
adder op and every zero-detect op.  The problems are to merge the
pseudos allocated to zero-detect and adder that the scheduler puts in
the same bundle, since they refer to the same CC FIFO slot.  Next
problem is how to allocate hard regs for the pseudos.  The insn
scheduler really knows how this ought to be done, so could do it
before the global-reg-alloc phase.  It could assign CC0..CC6
cyclically as destinations (i.e., assign CC0..CC6 to bundles 0..6,
then reassign CC0..CC6 to bundles 7..13, etc.).  At codegen time, the
backend could compute the difference between the CCn it wants to use
and the CCm assigned in this bundle in order to get the offset of CCn
in the FIFO.  Yes, such relative addressing of CC sets loses if
global-reg alloc later inserts insns to spill and fill quantities
to/from memory, but this machine can't access memory in a general way,
so that's not a possibility.

Comments?  Better ideas?


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