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]

Re: Question on gimplify.c:create_tmp_var


    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.


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