This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: question about scheduling optimization in machine description
- From: Spundun Bhatt <spundun at ISI dot EDU>
- To: Richard Henderson <rth at redhat dot com>
- Cc: gcc at gcc dot gnu dot org, bonzini at gnu dot org
- Date: Sat, 11 Sep 2004 10:00:51 -0700
- Subject: Re: question about scheduling optimization in machine description
- References: <4140F779.1020102@isi.edu> <20040910061554.GB1324@redhat.com>
Richard Henderson wrote:
On Thu, Sep 09, 2004 at 05:38:17PM -0700, Spundun Bhatt wrote:
On my architecture, floating point instructions run faster when put
backto back with no integer or load/store instructions in the middle.
So I want to ask the compiler to group as many such instructions
togather as possible. The reason is that FP unit is pipelined and it
stalls all instructions except other floating point instructions until
the float pipeline is clear. (to save on WB hazard detection).
I have thought about this a lot but ccant find a solution that will be
helpful... any ideas?
You may be able to do clever things with the scheduling DFA.
We do instruction bundling for pentiumpro this way, for instance.
Thanks to you a Paolo for the reply.
Unfortunately I omitted an important detail in my problem. The fact that
I am working on a gcc derived from 2.95.3 :((. I studied the new and old
internals book... and came to conclusion that both your replies refer to
the new scheduling method that is not available in 2.95.3. Sorry for not
mentioning this before. Is there anyway to do this in the 2.95.3 scheduler?
Thank you
Spundun
btw. I am considering just putting the old target directory in the new
gcc 3.4 's config directory .... do you think that can work? (within a
day or a week?)
Also examine the TARGET_SCHED_REORDER target hook. That'll
let you choose from the ready instructions to fill just
about any packing scheme you need. You'll have to track
the instruction state yourself in that case; there are other
hooks to enable that.
r~
--
If popularity breeds vulnerability, Apache should have far more
vulnerabilities than IIS. It doesn't.