public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* I need a GCC porting hint (or two) for an odd architecture...
@ 1999-09-16  8:46 Andrew Webber
  1999-09-16  9:34 ` Nick Ing-Simmons
                   ` (2 more replies)
  0 siblings, 3 replies; 6+ messages in thread
From: Andrew Webber @ 1999-09-16  8:46 UTC (permalink / raw)
  To: gcc

I might be off topic for this list for these questions...

I have been playing around with porting gcc to an odd architecture.  The
architecture is odd for a number of reasons, however, of most relevance
to my questions are memory operations.

In this architecture simple memory reads are actually made up of two
machine instructions - one to issue the read address and one to pick up
the read data.  I have made a machine description that uses a define
expand to split memory operations in the two parts but have come across
a problem when optimization is turned on as the first of my two
instructions gets optimized out (just before .c.flow is written out).  I
could issue the two instructions as assembly together, however, I wanted
to try going through RTL to see if I could use function units or
whatever to reschedule these instructions to reduce stalling for memory
reads.

In addition, my odd architecture consists of two groups of registers
where for a memory write one group can be used for the write address and
one for the write data - is there any pleasant way to communicate this
to gcc (I currently use the inelegant solution of crippling the machine
description to only allow write addresses from one group and write data
from the other).

Thanks,

Andrew.



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: I need a GCC porting hint (or two) for an odd architecture...
  1999-09-16  8:46 I need a GCC porting hint (or two) for an odd architecture Andrew Webber
@ 1999-09-16  9:34 ` Nick Ing-Simmons
  1999-09-30 18:02   ` Nick Ing-Simmons
  1999-09-16 23:41 ` Jeffrey A Law
  1999-09-30 18:02 ` Andrew Webber
  2 siblings, 1 reply; 6+ messages in thread
From: Nick Ing-Simmons @ 1999-09-16  9:34 UTC (permalink / raw)
  To: andreww; +Cc: gcc

Andrew Webber <andreww@videologic.com> writes:
>I might be off topic for this list for these questions...
>
>I have been playing around with porting gcc to an odd architecture.  The
>architecture is odd for a number of reasons, however, of most relevance
>to my questions are memory operations.
>
>In this architecture simple memory reads are actually made up of two
>machine instructions - one to issue the read address and one to pick up
>the read data.  

Cute.

>I have made a machine description that uses a define
>expand to split memory operations in the two parts but have come across
>a problem when optimization is turned on as the first of my two
>instructions gets optimized out (just before .c.flow is written out).  I
>could issue the two instructions as assembly together, however, I wanted
>to try going through RTL to see if I could use function units or
>whatever to reschedule these instructions to reduce stalling for memory
>reads.

When doing "odd architectures" it is best to lie to the compiler as little
as possible. So I suggest that the 1st insn should mention a "special" 
hard register (which represents the address or the read data) as an output, 
and the second mention it again as an input. 
That will build a dependancy between the two and you can add a "latency"
to the 1st insn so that second gets moved away from it.
It will get messy if this can be pipelined - i.e. several reads
in progress. It is easy enough to add more magic registers, but then GCC
will try and reorder the "collects" which may not match the pipelined arrival.

>
>In addition, my odd architecture consists of two groups of registers
>where for a memory write one group can be used for the write address and
>one for the write data - is there any pleasant way to communicate this
>to gcc (I currently use the inelegant solution of crippling the machine
>description to only allow write addresses from one group and write data
>from the other).

I am not sure I understand the restriction yet - but if two classes can be
swapped than you can give each class a name predicate etc. and have two 
alternatives:
       *class-1 = class2
or
       *class-2 = class1 

But GCC is not going to like it ;-) - REG_OK_FOR_BASE & co. get fixated
on the "one true base register" class.   

GCC is very bad at constraining registers where the choice of one hard 
register affects the validity of others. Many TI DSPs have similar restrictions
(e.g. which register is used as a "base" determines which registers are 
valid "index").  

I had (some) success by re-numbering registers in "pairs" (DI mode)
insisting that operands used the _same_ "pair" and then picking out High/low
as appropriate. I still tended to get a lot of register-register moves
that were not really necessary.  In your case I suecpect using 1/2 the 
possible registers like you do now is better than DI hackery.

-- 
Nick Ing-Simmons <nik@tiuk.ti.com>
Via, but not speaking for: Texas Instruments Ltd.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: I need a GCC porting hint (or two) for an odd architecture...
  1999-09-16  8:46 I need a GCC porting hint (or two) for an odd architecture Andrew Webber
  1999-09-16  9:34 ` Nick Ing-Simmons
@ 1999-09-16 23:41 ` Jeffrey A Law
  1999-09-30 18:02   ` Jeffrey A Law
  1999-09-30 18:02 ` Andrew Webber
  2 siblings, 1 reply; 6+ messages in thread
From: Jeffrey A Law @ 1999-09-16 23:41 UTC (permalink / raw)
  To: Andrew Webber; +Cc: gcc

  > In this architecture simple memory reads are actually made up of two
  > machine instructions - one to issue the read address and one to pick up
  > the read data.  I have made a machine description that uses a define
  > expand to split memory operations in the two parts but have come across
  > a problem when optimization is turned on as the first of my two
  > instructions gets optimized out (just before .c.flow is written out).  I
  > could issue the two instructions as assembly together, however, I wanted
  > to try going through RTL to see if I could use function units or
  > whatever to reschedule these instructions to reduce stalling for memory
  > reads.
The key here is to show that the memory read insn somehow uses a resource that
is set by the address issue insn.  The most likely reason flow deleted your
instruction is because it did not appear that the result of that instruction
was ever used.

One approach is to keep the two instructions together as a single insn until
after register reloading has completed, then use a define_split to break them
into component pieces for scheduling purposes.

  > In addition, my odd architecture consists of two groups of registers
  > where for a memory write one group can be used for the write address and
  > one for the write data - is there any pleasant way to communicate this
  > to gcc (I currently use the inelegant solution of crippling the machine
  > description to only allow write addresses from one group and write data
  > from the other).
I don't follow this.  But I'm suffering from a caffeine deficiency at the 
moment, so my brain isn't up-to-speed.  It seems like a fairly simple register
classing & constraint problem.

jeff

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: I need a GCC porting hint (or two) for an odd architecture...
  1999-09-16 23:41 ` Jeffrey A Law
@ 1999-09-30 18:02   ` Jeffrey A Law
  0 siblings, 0 replies; 6+ messages in thread
From: Jeffrey A Law @ 1999-09-30 18:02 UTC (permalink / raw)
  To: Andrew Webber; +Cc: gcc

  > In this architecture simple memory reads are actually made up of two
  > machine instructions - one to issue the read address and one to pick up
  > the read data.  I have made a machine description that uses a define
  > expand to split memory operations in the two parts but have come across
  > a problem when optimization is turned on as the first of my two
  > instructions gets optimized out (just before .c.flow is written out).  I
  > could issue the two instructions as assembly together, however, I wanted
  > to try going through RTL to see if I could use function units or
  > whatever to reschedule these instructions to reduce stalling for memory
  > reads.
The key here is to show that the memory read insn somehow uses a resource that
is set by the address issue insn.  The most likely reason flow deleted your
instruction is because it did not appear that the result of that instruction
was ever used.

One approach is to keep the two instructions together as a single insn until
after register reloading has completed, then use a define_split to break them
into component pieces for scheduling purposes.

  > In addition, my odd architecture consists of two groups of registers
  > where for a memory write one group can be used for the write address and
  > one for the write data - is there any pleasant way to communicate this
  > to gcc (I currently use the inelegant solution of crippling the machine
  > description to only allow write addresses from one group and write data
  > from the other).
I don't follow this.  But I'm suffering from a caffeine deficiency at the 
moment, so my brain isn't up-to-speed.  It seems like a fairly simple register
classing & constraint problem.

jeff

^ permalink raw reply	[flat|nested] 6+ messages in thread

* I need a GCC porting hint (or two) for an odd architecture...
  1999-09-16  8:46 I need a GCC porting hint (or two) for an odd architecture Andrew Webber
  1999-09-16  9:34 ` Nick Ing-Simmons
  1999-09-16 23:41 ` Jeffrey A Law
@ 1999-09-30 18:02 ` Andrew Webber
  2 siblings, 0 replies; 6+ messages in thread
From: Andrew Webber @ 1999-09-30 18:02 UTC (permalink / raw)
  To: gcc

I might be off topic for this list for these questions...

I have been playing around with porting gcc to an odd architecture.  The
architecture is odd for a number of reasons, however, of most relevance
to my questions are memory operations.

In this architecture simple memory reads are actually made up of two
machine instructions - one to issue the read address and one to pick up
the read data.  I have made a machine description that uses a define
expand to split memory operations in the two parts but have come across
a problem when optimization is turned on as the first of my two
instructions gets optimized out (just before .c.flow is written out).  I
could issue the two instructions as assembly together, however, I wanted
to try going through RTL to see if I could use function units or
whatever to reschedule these instructions to reduce stalling for memory
reads.

In addition, my odd architecture consists of two groups of registers
where for a memory write one group can be used for the write address and
one for the write data - is there any pleasant way to communicate this
to gcc (I currently use the inelegant solution of crippling the machine
description to only allow write addresses from one group and write data
from the other).

Thanks,

Andrew.



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: I need a GCC porting hint (or two) for an odd architecture...
  1999-09-16  9:34 ` Nick Ing-Simmons
@ 1999-09-30 18:02   ` Nick Ing-Simmons
  0 siblings, 0 replies; 6+ messages in thread
From: Nick Ing-Simmons @ 1999-09-30 18:02 UTC (permalink / raw)
  To: andreww; +Cc: gcc

Andrew Webber <andreww@videologic.com> writes:
>I might be off topic for this list for these questions...
>
>I have been playing around with porting gcc to an odd architecture.  The
>architecture is odd for a number of reasons, however, of most relevance
>to my questions are memory operations.
>
>In this architecture simple memory reads are actually made up of two
>machine instructions - one to issue the read address and one to pick up
>the read data.  

Cute.

>I have made a machine description that uses a define
>expand to split memory operations in the two parts but have come across
>a problem when optimization is turned on as the first of my two
>instructions gets optimized out (just before .c.flow is written out).  I
>could issue the two instructions as assembly together, however, I wanted
>to try going through RTL to see if I could use function units or
>whatever to reschedule these instructions to reduce stalling for memory
>reads.

When doing "odd architectures" it is best to lie to the compiler as little
as possible. So I suggest that the 1st insn should mention a "special" 
hard register (which represents the address or the read data) as an output, 
and the second mention it again as an input. 
That will build a dependancy between the two and you can add a "latency"
to the 1st insn so that second gets moved away from it.
It will get messy if this can be pipelined - i.e. several reads
in progress. It is easy enough to add more magic registers, but then GCC
will try and reorder the "collects" which may not match the pipelined arrival.

>
>In addition, my odd architecture consists of two groups of registers
>where for a memory write one group can be used for the write address and
>one for the write data - is there any pleasant way to communicate this
>to gcc (I currently use the inelegant solution of crippling the machine
>description to only allow write addresses from one group and write data
>from the other).

I am not sure I understand the restriction yet - but if two classes can be
swapped than you can give each class a name predicate etc. and have two 
alternatives:
       *class-1 = class2
or
       *class-2 = class1 

But GCC is not going to like it ;-) - REG_OK_FOR_BASE & co. get fixated
on the "one true base register" class.   

GCC is very bad at constraining registers where the choice of one hard 
register affects the validity of others. Many TI DSPs have similar restrictions
(e.g. which register is used as a "base" determines which registers are 
valid "index").  

I had (some) success by re-numbering registers in "pairs" (DI mode)
insisting that operands used the _same_ "pair" and then picking out High/low
as appropriate. I still tended to get a lot of register-register moves
that were not really necessary.  In your case I suecpect using 1/2 the 
possible registers like you do now is better than DI hackery.

-- 
Nick Ing-Simmons <nik@tiuk.ti.com>
Via, but not speaking for: Texas Instruments Ltd.

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~1999-09-30 18:02 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-09-16  8:46 I need a GCC porting hint (or two) for an odd architecture Andrew Webber
1999-09-16  9:34 ` Nick Ing-Simmons
1999-09-30 18:02   ` Nick Ing-Simmons
1999-09-16 23:41 ` Jeffrey A Law
1999-09-30 18:02   ` Jeffrey A Law
1999-09-30 18:02 ` Andrew Webber

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).