This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Status of tree-ssa work for Ada


I'm finishing some final testing, but I'm about ready to check in the work
I've done.

Right now, from the Ada side, I'm where I was with the function-at-a-time
work: the Ada RTS compiles without any ICEs or unexpected warnings.
I disabled the generation of Ada elaboration code as part of that work and
so still need to get that working again in order to actually run any Ada code.

I'm completing the testing of the changes with the other languages and it's
looking good.  It looks like I break g++.old-deja/g++.other/debug6.C, but I
can't fix that and it's in the "hole" that RTH and I have been talking about,
so I'm hoping he can resolve that issue.  It's likely there will be some
other failures on other targets and I'm hoping that others will be able to
give me a hand with those regressions.

Basically, the strategy I'm using is to treat GENERIC as if it's defined as
"that set of trees that the RTL expander supported just before the tree-ssa
merge".  That's not a very good definition, but at least it's operationally
precise.  There was a discussion of excluding some things from that set and
having any front ends that need to gimplify it, but I see no reason not to do
it in gimplify.c instead.  Knowlege of what's valid in GENERIC is restricted
to just that file and is no burden on the tree optimizers.  It's better to
keep the definition of GENERIC as clean as possible under the circumstances.

As far as GIMPLE is concerned I don't necessarily agree that disallowing
(e.g.) EQ_EXPR on aggregate types is the right approach, but I have done that
for now: gimplify.c does a similar transformation for '<' operations on
aggregate types as is done for variable-sized types for MODIFY_EXPR.

Various places in gimplification and the optimizers had slightly different
views of what's valid with references and LHS's (and implicitly the same
thing in an RHS).  What I changed it to be was to uniformly allow either a
single REALPART_EXPR or IMAGPART_EXPR or a nest of reference nodes that
handled_component_p returns nonzero for.

We discussed various other approaches, but this seemed best and is consistent
with the RTL expanders, which treat such a thing as a single operation.  We
can't split them up by taking the address of each and then dereferencing
because, in general, the sub-components are not addressable.  We can't do it
without taking the address because it would require large temporaries, and
possibly ones that are variable-sized.  We could convert the entire nest into
a some new operation that aggregated all the offsets (by calling
get_inner_reference when gimplifying), but that would lose too much
information (we can always decide to do that at some point later in the
process anyway if we feel it useful).

In order to support variable-sized types (e.g., as array elements), variable
field positions, and variable lower-bounds, I added two new fields to
ARRAY_REF and one to COMPONENT_REF.  These are passed as NULL_TREE by front
ends and much of the middle-end when creating the nodes and are filled in by
gimplification.  PLACEHOLDER_EXPRs are taken care of here.  This removes any
hidden values from the tree: values in the type trees (such as bounds,
positions, and sizes) will only be used by the RTL expanders if they are
constants.

The problems I ran into during this process were the variable positions,
bounds, and sizes I mentioned above; the fact that the Ada front end
generated complex trees of a form not seen before so some bugs were
undetected; and sharing problems relating to variables in types and object
sizes, bounds, and positions and related to nested subprograms.  These
changes fix all of those issues.

The changes are a few thousand lines, but the vast majority of it are
mechanical changes, mostly to front-ends and back-ends, to add extra args to
ARRAY_REF and COMPONENT_REF.  The largest changes were to gimplify.c.

I propose to commit these changes later today: they represent a significant
tree divergence and it would be good to get them committed once I've
completed a little more testing.  I think the overall approach has been
agreed on and it'll be easier to do any needed refinements to them once they
have been checked in.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]