This is the mail archive of the
mailing list for the GCC project.
Re: merging VTA: what does it take?
- From: Richard Guenther <richard dot guenther at gmail dot com>
- To: Alexandre Oliva <aoliva at redhat dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Sat, 25 Jul 2009 11:27:54 +0200
- Subject: Re: merging VTA: what does it take?
- References: <email@example.com>
On Sat, Jul 25, 2009 at 1:19 AM, Alexandre Oliva<firstname.lastname@example.org> wrote:
> So... ?It's been a long journey, but I think I'm at a point in which,
> even though VTA is not completely finished, it's already enough of an
> improvement that it could go in, be useful and get wider testing.
> To the best of my knowledge, all of the concerns and objections that
> were raised have already been addressed: we have low memory and
> compile-time overhead in general, and we have significantly improved
> debug information.
> Besides all the data that Jakub has already posted, Mark Wielaard has
> done some Systemtap testing, comparing debug information for parameters
> of inlined functions using a pristine Fedora kernel vs results using a
> vta4.4 compiler to compile the same kernel sources.
> Out of 42249 inlined function parameters for which some debug
> information was emitted, GCC 4.4 emitted location information for only
> 280, whereas the backport of VTA to GCC 4.4 emitted location information
> for as many as 7544.
> The careful reader will note that 34705 parameters still don't get
> location information. ?That's a lot. ?No investigation has been done as
> to how many of them are indeed unavailable, and therefore couldn't
> possibly and shouldn't have got debug location/value information, but
> I'd be surprised if it's this many. ?As I pointed out before, the code
> is not perfect, and there is certainly room for further improvements,
> but waiting for perfection will take too long ;-)
> Seriously, if VTA could be merged soonish, or at least accepted soon for
> a merge at a later date, Fedora would adopt it right away in its
> development tree, and then we'd get much broader testing. ?So, what does
> it take to get it merged soonish, even if not enabled by default?
I didn't see the generic RTL parts getting a single review yet and I'd
like you to re-post the tree pieces (you can do it as a single patch), just
so I can double-check and ack them. I think we have a sort-of consensus
that we would like to have VTA in 4.5.
For the merge itself there's still this ChangeLog thing that needs to be done
and checking that the primary archs (or at least the majority of them)
pass bootstrap and testing (not that I expect any target specific problems).
Oh, and of course approval is missing (you may get pieces from me, but
I don't feel comfortable to review and approve RTL infrastructure changes).