| |||||||||||||
|
| |||||||||||||
pcc seeks contributions to reach 1.0 milestonepcc seeks contributions to reach 1.0 milestonePosted Nov 18, 2008 3:55 UTC (Tue) by RandyBolton (subscriber, #6186)Parent article: pcc seeks contributions to reach 1.0 milestone
I found this recent presentation from Anders Magnusson on the web that gives a good overview of the current state of PCC:
Bringing PCC into The 21th century
(Log in to post comments)
Good link Posted Nov 18, 2008 7:59 UTC (Tue) by roskegg (subscriber, #105) [Link]
Ragge's presentation that you linked to was really nifty. I didn't realize a C compiler could be so simple.
I hope he finishes pdp10 support at some point, and that NetBSD and OpenBSD get ported to the PDP10. It would be a fun honeypot to leave running.
Good link Posted Nov 18, 2008 16:03 UTC (Tue) by nix (subscriber, #2304) [Link]
The *very* early C compilers are even more stunningly simple, and they
probably work quite well for PDP10s, and are good examples even now of simple parsers.
But if you want to get decent performance on modern hardware you *need*
So perhaps they plan for this to stay forever in the ghetto of 1980s and
Good link Posted Nov 19, 2008 7:28 UTC (Wed) by ragge (guest, #55254) [Link]
Please look at the presentation again. The things you mentions are already put in the compiler. The initial design of the compiler made it very easy to add state-of-the-art optimizing stuff. I think especially the multi-class register allocator is one of the best available today.
Currently the code generated is between 0-10% slower than code generated by gcc, and most of the time "lost" is due to not-yet added optimizations. Still, the compiler runs around 15 times faster than gcc.
pcc seeks contributions to reach 1.0 milestone Posted Nov 18, 2008 16:00 UTC (Tue) by nix (subscriber, #2304) [Link]
Good grief. I had no idea pcc was *that* primitive. They will hit a wall
as hard as carborundum as soon as they try to do decent optimizations. (Why? Look at the IR. Try to figure out how to rewrite the thing into SSA form without significant agony. I gave up. And without SSA, you lose, oh, pretty much all high-level optimizations described in the literature. It's one reason why GCC was held back for so long... and now another compiler is blithely heading off down the same wrong track. *sigh*)
pcc seeks contributions to reach 1.0 milestone Posted Nov 19, 2008 7:34 UTC (Wed) by ragge (guest, #55254) [Link]
Hm, which compiler did you look at? :-) The SSA conversion code has been into pcc for years, I just haven't finished it up, it has not been my main priority.
If you have a compiler with a reasonable internal design, none of the standard optimizing algorithms are especially difficult to add (like SSA conversion, graph-coloring register allocator, strength reduction etc.)
pcc seeks contributions to reach 1.0 milestone Posted Nov 19, 2008 8:36 UTC (Wed) by nix (subscriber, #2304) [Link]
I think I must be getting it from the wrong place. Never. Do. Research.
While. Ill. *slaps self*
pcc seeks contributions to reach 1.0 milestone Posted Nov 20, 2008 0:16 UTC (Thu) by bboissin (subscriber, #29506) [Link]
You should really consider having SSA as your primary IR. It makes so many things trivial... I especially like the IR used by libfirm (http://www.info.uni-karlsruhe.de/software/libfirm/index.p... ). It gives you many things for free (SSA all along, no dead code, etc.)
pcc seeks contributions to reach 1.0 milestone Posted Nov 20, 2008 7:51 UTC (Thu) by nix (subscriber, #2304) [Link]
I'm fairly sure 'having SSA as your primary IR' makes no real sense: it's
like saying 'having assignment as your primary IR'. Having your primary IR, *whatever it is*, be in SSA form for as much of the time as possible is probably a very good thing (although I'm not sure how you could convert *directly* to it: you'd need to go through a non-SSA form immediately after parsing, and you'd need to go through another one immediately before conversion to assembler or your output would be ludicrously inefficient).
pcc seeks contributions to reach 1.0 milestone Posted Nov 20, 2008 16:49 UTC (Thu) by bboissin (subscriber, #29506) [Link]
"you'd need to go through another one immediately before conversion to assembler or your output would be ludicrously inefficient"
Coalescing is done during the Out-of-SSA pass (and it would be very inneficient to do the Out-of-SSA by replacing each phi with a move), if you're in CSSA form, just replace every phi-related variable with a unique variable and that's all (so the hard part is the conversion to CSSA).
As for the IR, I believe SSA can really influence your IR, so it's not just a property (you need parallel moves, etc). Libfirm does that very nicely from what I've seen.
pcc seeks contributions to reach 1.0 milestone Posted Nov 20, 2008 22:36 UTC (Thu) by nix (subscriber, #2304) [Link]
I only just learned of libfirm from this thread, and it looks *deeply*
cool. I can think of half a dozen potential uses for it already :)
pcc seeks contributions to reach 1.0 milestone Posted Dec 4, 2008 17:15 UTC (Thu) by salimma (subscriber, #34460) [Link]
LLVM IR is almost entirely in SSA form -- it still has pointers, but apart from that, assignments must be to fresh "registers"
pcc seeks contributions to reach 1.0 milestone Posted Dec 5, 2008 0:44 UTC (Fri) by nix (subscriber, #2304) [Link]
Oh yes, agreed. I was being pedantic in another area, that it makes no
sense to say that you use SSA *as* your IR, because it's not an IR, just a set of rules that constrain that IR (it's applicable to many different sorts of IR, but *you* know that.)
|
|
||||||||||||