new IA64 backend

Hi everyone,

  I've just checked in an IA64 backend to LLVM! Be warned, it's pretty rough right now. Here are some of the known defects:

  - No varargs
  - No alloca
  - No instruction scheduling/bundling of any sort

  ...or in other words, it breaks often and when it does work, it's a dog. On the plus side, it _does_ have a tasty new pattern instruction selector. :slight_smile: Beyond fixing the first two gaping holes above, I'm planning on implementing a reasonably serious scheduler/bundler, something more or less along the lines of that described here:

  http://www.jilp.org/vol6/v6paper2.pdf

  ..hopefully that'll be done in time for xmas. Beyond that, a JIT would be a very nice addition, and I'll give that a shot too if I can't sucker anyone else into doing it for me. :wink:

  Well, thanks to LLVM hackers one and all, but especially Chris for making the whole endeavour rather painless and Andrew for the Alpha backend from which I cut and pasted^W^W^Wlearned a lot.

  Duraid

Woo hoo! And There Was Much Rejoicing in IA64 Land :-).

Hi everyone,

  I've just checked in an IA64 backend to LLVM! Be warned, it's pretty
rough right now. Here are some of the known defects:

  - No varargs

What are your issues here? Or are they simply at the "not implemented
so I don't know" stage? Namely, I am working on some varargs changes
that may or may not be applicable to you.

  - No instruction scheduling/bundling of any sort

So this one needs to be coordinated. Next week, I might see about
adding MachineInstruction support to the SelectionDAG so you can load up
a DAG post-ISel and then spit it back out scheduled.

Andrew Lenharth
http://www.lenharth.org/~andrewl/

Andrew Lenharth wrote:

- No varargs

What are your issues here? Or are they simply at the "not implemented
so I don't know" stage?

The two bugs I mentioned (no varargs, no alloca) are pretty much two sides of the same coin: I'm ignoring the IA64 stack frame layout (for no good reason), so these don't work. Actually, varargs seems particularly simple on IA64, so I'll swat these two bugs pretty soon.

Namely, I am working on some varargs changes
that may or may not be applicable to you.

Hmm. :slight_smile:

- No instruction scheduling/bundling of any sort

So this one needs to be coordinated. Next week, I might see about
adding MachineInstruction support to the SelectionDAG so you can load up
a DAG post-ISel and then spit it back out scheduled.

That would be much appreciated, particularly if it means that we can have scheduled MachineInstructions living alongside DAGs in such a way that changing the DAG (adding/removing a couple of instructions, say) doesn't _necessarily_ require rescheduling the whole function. I'm thinking of a future JIT here, where it would be nice to be able to sprinkle/reap instrumentation code over functions at high speed.

  Duraid

Al Stone wrote:

Woo hoo! And There Was Much Rejoicing in IA64 Land :-).

So we see here that Al has not yet run the test suite. :wink:

Hmm. For those _not_ in IA64 land, here a few random things that might be interesting:

  - IA64, perhaps more than any other general purpose computing architecture, depends on something like LLVM for high performance. Whole-program optimization simply 'falls out' with LLVM, yet this is more or less the limit of what the Intel and HP compiles can do. Life-long optimization is particularly important on IA64, because there's only so much that the hardware can do to "help itself." It's true that some aspects of IA64 are completely orthogonal to things like out-of-order execution and one can imagine a monster "Itanium 4" (4 as in "Pentium 4" :wink: ), but I personally hope that Intel doesn't go down that path - at least not until LLVM/IA64 has had a chance to conquer the world^W^W^Wprove itself in the field. Anyone who saw Intel's presentation at this year's ISSCC will probably hope so too; an Itanium 2/12MB @2.5GHz dissipating ~50W can be a frightfully powerful and fairly _efficient_ device for the 90nm node, but it only shines if you have the compiler support there.

  - IA64 specifies performance gathering abilities that are (to my knowledge, anyway) simply unparalleled. This might be interesting/useful for the LLVM-reoptimization folk.

  - JITs can be particularly quick on IA64. (No, really!) Register allocation is a piece of cake for example, and the IA64 machine model is quite simple.

  - The IA64 backend is a little odd in that it defines a register class for booleans, not just i64s and f64s.

  - IA64 users currently suffer from the lack of a solid, high-performance, easy-to-use open-source compiler. There are some good open-source compilers (ORC, IMPACT) but these break like twigs, and aren't really intended for production use. There's GCC which is _reasonably_ solid these days but the performance ranges from poor to underwhelming. I'm hoping that llvm-gcc will become an alternative for those who can't/won't use the Intel or HP compilers.

  Duraid

To me, I think the correct approach is to look at instruction selection in terms of dag rewriting, not the current pattern-matching-and-machineinstr- emission process we have now.

In particular, I think the only real way to handle X86 register pressure is to produce a dag labeled by X86 opcodes, then have a register pressure aware emission process (like the Goodman and Hsu approach). If the other backends worked this way, they could naturally do DAG-based scheduling as well.

I guess I don't really see the point of going:

DAG ----select---> MachineInstrs -> DAG ----schedule----> Machineinstrs

When this should work:

DAG ----select---> DAG ----schedule----> MachineInstrs

This was in my plan to implement, but unfortunately I won't have time to play with this for a while. :frowning:

-Chris

Right, but once the MI are RAed, you want to be able to do a post-pass
scheduling also. So you need to be able to take a MBB and produce a
DAG. A scheduler obviously wouldn't care how it came about having a
DAG. And it is easier to do the lift from a MBB to a DAG than to change
the entire ISelPattern process at the moment. Baby steps.

Andrew

Oh right, for post-pass scheduling I completely agree.

-Chris