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: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Eric Botcazou <ebotcazou at adacore dot com>
- Cc: Richard Biener <richard dot guenther at gmail dot com>, <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 13:25:51 +0000
- 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> <CABu31nOpcf1EivKXYy-i4Czm84aSv+hOYhrSPpefzNVTjjNW0Q at mail dot gmail dot com> <CAFiYyc3OZhg0NvnMqkN9CLu4f6oGiV2GFM55JE17MjDAgj8Jsw at mail dot gmail dot com> <1608460 dot i0thhgDpq4 at polaris>
On Wed, 13 Nov 2013, Eric Botcazou wrote:
> > Eric, would emitting GIMPLE from gigi make that a lot more
> > complicated? That is, would you prefer to have an even
> > higher-level early GIMPLE (considering stuff like TARGET_EXPR
> > and WITH_CLEANUP_EXPR, etc.)?
>
> This would mean privatizing in gigi all the machinery needed to support types
> with variable size scattered over the middle-end (tree.c, fold-const.c and
> stor-layout.c) unless you want to make them first-class citizens in GIMPLE,
> which is very unlikely I presume. Not undoable, but IMO that would be a step
> backwards from GENERIC in which you can express a lot a things, and not only
> the semantics of C and its close relatives.
C has already (GCC 4.5 and later) largely moved to using its own logic for
variable size types, to ensure that sizes get evaluated at exactly the
right time according to C language semantics; I think the only generic
pieces it relies on are the lowering of VLA objects to explicit stack
allocation and deallocation.
Other places where GENERIC provides something that no doubt seemed
convenient originally, but is less useful when you want to ensure things
are evaluated at exactly the time implied by language semantics, include
SAVE_EXPRs and pre/post increment/decrement. The generic gimplification
logic for the latter caused issues in the past when it turned out not to
match C11 semantics; C now explicitly creates the required temporaries in
the case of increment / decrement / compound assignment of atomic types,
and will probably need to move to using more of its own logic for compound
assignment in general to fix bug 58943. I'd be happy for front ends to
move to doing all these things themselves, rather than trying to define
GENERIC in a way that works for every language's requirements on when
things are evaluated and when storage is allocated / deallocated.
--
Joseph S. Myers
joseph@codesourcery.com