ia64 projects

[Jim Wilson]

In article < OFA91E2757.0853FAB8-ON882569CF.0082A6E5@LocalDomain > you write:
>Is there an existing wish list of projects for IA-64 code generation
>and/or optimization?

There is no formal list.  There are things that we know that we don't have
that we would like to have.

We don't have control speculation or data speculation.  There is a patch
written for control speculation about a year ago, but I don't think anyone
ever looked at it other than the author Stan Cox.  It would likely need a lot
of rewriting to be useable again.  There was one aborted attempt to add data
speculation by Bernd Schmidt.

We don't have a good Itanium hardware description.  There is an improved
pipeline description scheme that was written by Vladimir Makarov.  However,
it hasn't been submitted to the FSF yet, and it is unclear when it will be,
so for now we aren't using it.  When we did try to use it, we didn't get
any noticable speedup.  It was unclear whether this was due to limitations
with the scheduler, or whether there was something wrong with the Itanium
pipeline description.

We don't have software pipelining.  There is code written by Vladimir Makarov
for modulo contrained software pipelining (or something like that), but I
don't know how well it works, and it has no IA-64 specific knowledge, so it
doesn't support interesting features like register rotation.  This code has
not been submitted to the FSF, and requires the new pipeline description scheme
which is also not submitted to the FSF, so we can't use it.

The support for predication could be improved.  There is currently little or
no knowledge of predication outside the if-cvt.c file, so there are a number
of optimization passes that are suboptimal when predicated code is present.
Register allocation for instance, I don't think it will reuse registers in
mutex code blocks because it doesn't know about predication.  The scheduler
was creating lots of false dependencies for a while, but that may have been
fixed already, I'm not sure.

That is kind of a general wish list based on interesting processor features.
So far, I haven't had any time to look at code and figure out what needs
to be improved.  Just getting the toolchain working well enough, and complete
enough, for OS releases has taken almost all of my time so far.

There are ??? comments scattered through the ia64 backend, some of which
point out optimization opportunities.  Most of these are small local opts
though, so we may not get much performance from them.

I suspect that we aren't generating enough ILP to really take advantage
of the architecture.  So improving optimizations that create ILP might be
a good first step.  Perhaps some code replication would be useful.  Or perhaps
improving predication/speculation support would help.  I would expect that
scheduler improvements tie into this.  We probably need an agressive cross
block scheduler to get much benefit from any of these areas.  I doubt we want
to go as far as trace scheduling, but there is probably something intermediate
that would be useful.

I also suspect that the, um, idiosyncracies of the Itanium pipeline are
causing problems.  Some operations are a lot slower than one would expect.
Like dynamic shifts, which are effectively 10 cycles unless you schedule
them right or emit some nops after them in which case they are 4 cycles.
We don't get this right.  There are a lot of cache pipeline flush cases
if you put stores to close.  Some coalescing of stores might be useful to
avoid this.  Using alternate code sequences might be useful in some cases.
The cost of moving integer values to/from the FP registers for the multiply
(xma) instruction might make other code sequences faster.  I saw a message
today pointing out that we are moving values into branch registers too late.
There are likely other things that could be improved in this area.

We recently started emitting entire functions instead in a high level IL
instead of one statement at a time.  This introduces the possibility of
adding high level optimizations such as loop transformations.  We have
a little bit of dependence analysis, but it really isn't hooked into anything
yet.  The C++ front end does function inlining on the high level IL, but the
C front end doesn't yet.  This needs to be fixed.  The C front end is still
using a low level function inliner which can't handle any complicated call
sequence, which includes HFA arguments.  This means functions using the
complex FP types can't be inlined.  This hurts glibc math library performance.

We have a little bit of infrastructure for profile directed feedback, but
we haven't tried to use it yet, and it probably needs some maintenance work
before it will be usable again.  We probably should only rely on this as
a last resort though.  This is inconvenient for many applications.

I just recently got back from a 3 week vacation, and haven't caught up on
my gcc reading yet, so some of this info might be out of date.

>Is there a separate forum for communication about IA-64 work in gcc?

The ia64-linux (formerly Trillian) group has a private mailing list for
the toolchain, but I'd rather not use it anymore, because it is private.  There
is a public list linux-ia64@linuxia64.org but it mostly gets used by kernel
developers.  It might be feasible to use it for some linux/gcc discussions
though.  For now, the regular gcc lists are probably the best choice.  If we
remember to put ia64 in the subject line, it should be possible for people
to follow just the ia64 threads if that is all they want to read.

Jim