public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Question on parallel execution inside the processor
@ 1998-06-23  6:30 Martin Kahlert
  1998-06-23 15:04 ` Joern Rennecke
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: Martin Kahlert @ 1998-06-23  6:30 UTC (permalink / raw)
  To: egcs

Hi,
is there any pass in egcs, which tries to schedule instructions
in a way, that no pipeline stalls occur any more?

The haifa scheduler optimizes on RTL code - doesn't it?
So it can't know anything about assembler instructions,
which can only be executed in pipeline X and therefor 
shouldn't be preceeded by instructions which only
work in X, too. A good compiler would try to put
instructions in between.

So the question is:
Is there any part of gcc, which tries to take advantage
of parallel execution inside the processor and if the answer
was yes, where does it get its info about that from?

Thanks for any help,
Martin.

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

* Re: Question on parallel execution inside the processor
  1998-06-23  6:30 Question on parallel execution inside the processor Martin Kahlert
@ 1998-06-23 15:04 ` Joern Rennecke
  1998-06-23 16:21 ` Michael Meissner
  1998-06-23 19:23 ` Jeffrey A Law
  2 siblings, 0 replies; 4+ messages in thread
From: Joern Rennecke @ 1998-06-23 15:04 UTC (permalink / raw)
  To: Martin Kahlert; +Cc: egcs

> The haifa scheduler optimizes on RTL code - doesn't it?
> So it can't know anything about assembler instructions,
> which can only be executed in pipeline X and therefor 
> shouldn't be preceeded by instructions which only
> work in X, too. A good compiler would try to put
> instructions in between.

Whatever pipeline X is for your target, it should probably possible to
define it as a function unit.  Both the old scheduler and the haifa
scheduler handle scheduling for multiple function units.

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

* Question on parallel execution inside the processor
  1998-06-23  6:30 Question on parallel execution inside the processor Martin Kahlert
  1998-06-23 15:04 ` Joern Rennecke
@ 1998-06-23 16:21 ` Michael Meissner
  1998-06-23 19:23 ` Jeffrey A Law
  2 siblings, 0 replies; 4+ messages in thread
From: Michael Meissner @ 1998-06-23 16:21 UTC (permalink / raw)
  To: martin.kahlert; +Cc: egcs

Martin Kahlert writes:
| Hi,
| is there any pass in egcs, which tries to schedule instructions
| in a way, that no pipeline stalls occur any more?

The schedulers, though they don't guarantee that NO pipeline stalls
occur (they assume that the machine has latches to stall properly if
they can't find an instructin to fill).  If you need to add NOPs
though, you need to do it in the various final hooks such as
FINAL_PRESCAN_INSN.  You might want to look at the MIPS
final_prescan_insn and mips_fill_delay_slot functions, which used to
do this type of filling until the work was shifted to the assembler.

| The haifa scheduler optimizes on RTL code - doesn't it?
| So it can't know anything about assembler instructions,
| which can only be executed in pipeline X and therefor 
| shouldn't be preceeded by instructions which only
| work in X, too. A good compiler would try to put
| instructions in between.

Actually both schedulers know about the pipelines, assuming you
describe them in the machine descriptions.  In theory, each RTL is
supposed to represent one assembly language instruction.  What I tend
to do is make the rtl generic so that the early passes will optimize
things, and then use the insn splitting facility (which the schedulers
call) to properly break things down into one RTL/assembly language
instruction.

| So the question is:
| Is there any part of gcc, which tries to take advantage
| of parallel execution inside the processor and if the answer
| was yes, where does it get its info about that from?

You want to look at Machine Description -> Insn Attributes -> Function
Units for more information about how to describe the function units.
Also look up the target macros ADJUST_{COST,PRIORITY} and ISSUE_RATE.

| Thanks for any help,
| Martin.

-- 
Michael Meissner, Cygnus Solutions (Massachusetts office)
4th floor, 955 Massachusetts Avenue, Cambridge, MA 02139, USA
meissner@cygnus.com,	617-354-5416 (office),	617-354-7161 (fax)

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

* Re: Question on parallel execution inside the processor
  1998-06-23  6:30 Question on parallel execution inside the processor Martin Kahlert
  1998-06-23 15:04 ` Joern Rennecke
  1998-06-23 16:21 ` Michael Meissner
@ 1998-06-23 19:23 ` Jeffrey A Law
  2 siblings, 0 replies; 4+ messages in thread
From: Jeffrey A Law @ 1998-06-23 19:23 UTC (permalink / raw)
  To: Martin Kahlert; +Cc: egcs

  In message < 199806231329.PAA27951@keksy.mchp.siemens.de >you write:
  > Hi,
  > is there any pass in egcs, which tries to schedule instructions
  > in a way, that no pipeline stalls occur any more?
The scheduler attempts to do this.

  > The haifa scheduler optimizes on RTL code - doesn't it?
Yes.

  > So it can't know anything about assembler instructions,
Nor does any other pass in the compiler.

  > which can only be executed in pipeline X and therefor 
  > shouldn't be preceeded by instructions which only
  > work in X, too. A good compiler would try to put
  > instructions in between.
GCC does this.  Basically each hunk of RTL has a series of attributes
which describe the type of operation it performs.

In the machine description we can map from instruction types to
pipeline units.  Thus the scheduler has the information it needs
to schedule instructions to avoid pipeline stalls.


jeff

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

end of thread, other threads:[~1998-06-23 19:23 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1998-06-23  6:30 Question on parallel execution inside the processor Martin Kahlert
1998-06-23 15:04 ` Joern Rennecke
1998-06-23 16:21 ` Michael Meissner
1998-06-23 19:23 ` Jeffrey A Law

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).