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. :) 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. ;) 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
On Fri, 2005-03-18 at 05:04 +0900, Duraid Madina wrote:> I've just checked in an IA64 backend to LLVM!Woo hoo! And There Was Much Rejoicing in IA64 Land :-). -- Ciao, al ---------------------------------------------------------------------- Al Stone Alter Ego: Linux & Open Source Lab Debian Developer Hewlett-Packard Company http://www.debian.org E-mail: ahs3 at fc.hp.com ahs3 at debian.org ----------------------------------------------------------------------
On Fri, 2005-03-18 at 05:04 +0900, Duraid Madina wrote:> 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 varargsWhat 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 sortSo 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:> On Fri, 2005-03-18 at 05:04 +0900, Duraid Madina 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. :)>> - 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:> On Fri, 2005-03-18 at 05:04 +0900, Duraid Madina wrote: > > Woo hoo! And There Was Much Rejoicing in IA64 Land :-).So we see here that Al has not yet run the test suite. ;-) 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" ;) ), 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