Question on gimplify.c:create_tmp_var
Richard Kenner
kenner@vlsi1.ultra.nyu.edu
Sun Jun 6 21:50:00 GMT 2004
What a trivial 1-1 mapping problem. I do believe that this is
known technology.
No, it's not at all trivial. Nor is it 1-1. What you have is a FIELD_DECL
of a base type. What you need to find is the corresponding FIELD_DECL
of some other type that's a subtype of the base type. That can only be
done with a search, which is linear in the number of fields. That means
the compilation cost for a reference to each field is quadratic in the
number of fields. We need to avoid quadratic algorithms.
But this implementation "detail" is ignoring the main problem: this is
a fairly major breakage of the language type mechanism. We canonicalize
things by always converting to the base type. If we don't do that, every
type of operation is needs to be special-cased.
Sure, this can probably be made to work, but it's taking what's already
one of the most complicated cases in Ada and making it that much harder.
I don't see what's wrong with the current solution: all it means is a
few-line change in one routine.
Indeed, since it seems as if FIELD_DECLS are globally unique, you
could use one map for all of the remapped fields in all of the types
of the entire program. Which would eliminate a lot of fixed
per-datastructure overhead.
I don't follow. You mean create some sort of two-dimensional hash table
mapping the pair (original FIELD_DECL, subtype) to the new FIELD_DECL?
Again, I don't see this as a problem at all. Very like the existing
situation in C++.
Yes, but remember, this and the previous are just *two* cases. There
are others and then there are the cases that involve doing two or more
of these things simultaneously. The reason for the canonicalization is
to keep the cases simple.
More information about the Gcc
mailing list