?

Log in

No account? Create an account

Previous Entry | Next Entry

nightlife

GCC Developers' Summit, Day 2

  • 23rd Jun, 2005 at 11:59 PM

Today I attempted to have the conference breakfast again. This was a spectacularly poor move on my part. How a professional restaurant kitchen could serve up burnt hash browns is beyond my conception. I think they're scammers really. A gallon of coffee costs over $50 CDN at this place. Not only that, the coffee isn't even any good.

There were four brilliant talks today that really were must-sees:

Compilation Wide Alias Analysis
by Ken Zadeck kicked off the day. He talked about several optimizations that are slated for inclusion in GCC. These centred around analysing the GIMPLE representation for behaviour and optimising out useless (but safe) steps.
Interprocedural Constant Propogation in GCC
was a very good talk by Razya Ladelsky and Mircea Namolaru. They described the improvements that IBM Haifa is trying to achieve. They've got a constant propogator that works on the whole programme, which is really nice to see. This does, however, require that the entire programme is known in advance, but this has been mostly solved with the -fwhole-programme flag. This kind of work lays the foundation for other more complicated interprocedural optimisations, so I'm very glad they're doing it.
Inter-Module Analysis in GCC
was presented by Geoff Keating. He presented his work on getting cc1 to take in more than one source file at a time, before generating an object file. Of course, this is needed if you do want to perform operations across modules, because currently the compiler throws away all it knows when it quits. What Geoff discovered was that GCC does fairly well with resources when compiling large programmes. I think that this is particularly nice work, since it means that I'll be able to justify buying myself a nice new computer. Oh yes, build systems will probably need a bit of reworking for this, I think.
A Propagation Engine for GCC
was Diego Novillo's talk on infrastructure. He presented a talk last year on value-range propogation (VRP) and this paper came out of that work. When he was implementing VRP, he realised that he was doing the work for constant propogation all over again. So he wrote an engine that operates on GIMPLE and lets anyone do propogation rather with a nice tokenised interface. I think lots of people will be happy to use this infrastructure, especially since this type of work seems to be quite popular.

John Anglin, Jeff, and I lunched at the Royal Thai. I went here last year with elliptic_curve and I swear we ate at this restaurant once a day. The food this time was not quite up to snuff, as it had been before. I had the ส้มตำ (Som Tam) which was incredibly disappointing. Perhaps it was an off-day for them, but I'll have to find out next month. The curry was still quite good and I took some of it back to the hotel to eat for breakfast tomorrow. John noted that yesterday's talks were all about destroying the debugger's ability to make sense of the object code. We all agreed and tried to brainstorm ways to fix this. But we really couldn't think of an interface that would make this understandable at all.

I've been doing a good job at representing NITI at these sorts of conferences. Today I had someone come up to me and talk about what we do. And while asking about our distribution, they also asked about autonomic computing. musicdieu got into a discussion about autonomic computing with some IBM fellows about the work we were doing. So we are starting to become a recognised name in technical circles, it seems.

For dinner, Jim and Luke decided that it was their turn to cook. They invited Angie over again, and we sprung them for a surprise by asking Matthew Wilcox, Danielle, and Jody McIntyre over. Dinner was quickly devoured by everyone and then the discussion went on for a very long time. I stayed awake for far longer today, for which I was quite impressed. I nodded off only in very few of the talks.


Comments

( 8 comments — Leave a comment )
roju
27th Jun, 2005 18:14 (UTC)
GCC backend
None of the talks you've linked mention anything about the GCC backend, but I'm curious. With all the work (see parrot, pugs) going on with perl6 and parrot development, I've had a weird tingle to get gcc to target parrot. Any idea how difficult that would be? I realize it's a bit of an open ended question, but mayhaps you'll have some idea, what with having been to a GCC conference and all :) Does my question even make sense?
roju
27th Jun, 2005 18:27 (UTC)
Re: GCC backend
None of the talks you've linked mention anything about the GCC backend

Whoops, not particularly true. I suppose I should have said the platform-dependant section of the back-end.
sfllaw
27th Jun, 2005 18:48 (UTC)
Re: GCC backend
There was that talk about the Cell processor. There were some back-end dependant parts to implementing that architecture.
roju
27th Jun, 2005 19:41 (UTC)
Re: GCC backend
What's your opinion of the cell, anyway? There's been a lot of hype. :)
sfllaw
27th Jun, 2005 20:10 (UTC)
Re: GCC backend
It looks like a great CPU with lots of promise.

Sadly, programmers are idiots and therefore the co-processors will probably be under-utilized, or (even worse) blocking I/O. This will probably cause performance to be lousy, people will give it horrible reviews, and it will die.
sfllaw
27th Jun, 2005 18:52 (UTC)
Re: GCC backend
Writing a new GCC backend is not particularly easy, because you have to begin groking RTL. This is not impossible though, and would be rather interesting.

However, that seems a little folly since Parrot is not your standard machine. You'd probably have to do some overhauling of the entire compiler to propogate "string" as a type down into the RTL level.

You may have more success making a "backend" that converts the GIMPLE representation into PIR.
roju
27th Jun, 2005 19:46 (UTC)
Re: GCC backend
Hrm. It'd stink to have to cut out the whole middle-tier and lose some of the nifty new optimization stuff. Although it's true that Parrot isn't exactly just another low-level instruction set. I should do some digging around in the GCC docs and see what's possible. Seems like it would help parrot become the everywhere VM it wants to be if it could trivially run any program that GCC can compile.

I'm concerned that C style code might not adapt well though. I haven't done more than follow parrot development very superficially, so I have no idea how pointer ops, for instance, would translate.
sfllaw
27th Jun, 2005 20:08 (UTC)
Re: GCC backend
You don't lose any of the new optimisation passes by translating GIMPLE. You do lose the old RTL-based ones, though. That's not such a large loss.

Looking at Parrot and its C-structure PMCs, it looks like a naïve implementation is possible. Fundamentally, GIMPLE still is pointer-based, so it may be difficult to convert C-style structures into Parrot-style structures.
( 8 comments — Leave a comment )