This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Great example of why "everything is a tree" sucks
- From: Eric Botcazou <ebotcazou at adacore dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: gcc at gcc dot gnu dot org, Steven Bosscher <stevenb dot gcc at gmail dot com>, Diego Novillo <dnovillo at google dot com>, Jakub Jelinek <jakub at redhat dot com>, Jeff Law <law at redhat dot com>
- Date: Wed, 13 Nov 2013 18:20:20 +0100
- Subject: Re: Great example of why "everything is a tree" sucks
- Authentication-results: sourceware.org; auth=none
- References: <528288B3 dot 8010109 at redhat dot com> <1608460 dot i0thhgDpq4 at polaris> <CAFiYyc2wBrMJHwaev_Y7H31MDSUX0FAO--JHNa_R5Rt=rvotwQ at mail dot gmail dot com>
> Yeah, that's why I am asking. I suppose you are refering to
> gimplify_type_sizes and the required lowering of ARRAY_REFs and
> COMPONENT_REFs? Yes, I'd not make them first class citizens
> in the GIMPLE that the optimizers see but I'm fine with having
> high-GIMPLE support for them, doing a lowering pass on GIMPLE.
Yes, plus the machinery in tree.c and stor-layout.c for types with self-
referential size.
> Do you see any benefits in emitting "high" GIMPLE (besides eventually
> some minor compile-time and memory-usage improvements)? That is,
> would some things be easier to do? [you'd also lose any folding
> that generating GENERIC would have done]
We cannot lose the folding on offset/size expressions of types in Ada,
otherwise Ada software making heavy use of types wouldn't compile anymore.
That's why I also mentioned fold-const.c, all the size_* routines and their
dependencies would need to be privatized as well. I can think of marginal
benefits like more direct transfert of optimization hints on loops for
example, but nothing really decisive.
--
Eric Botcazou