On 8/8/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Ollie Wild wrote:
> > On 8/8/07, Michael Matz <[EMAIL PROTECTED]> wrote:
>
> Ollie, thanks for patiently trying out different approaches.
>
> > I think the primary purpose of the middle end is to provide a
> > representation which captures the semantics of a program at a
> > sufficiently high level to enable efficient optimization. COMPLEX_CST
> > and COMPLEX_TYPE are a good example. In theory, the middle end has
> > enough information to optimize complex arithmetic based solely on the
> > constituent operations on real and imaginary components, but it's
> > easier to deal with the complex number as an atomic unit.
>
> I agree.
>
> When I discussed this with Ollie, my feeling was that, yes, it's
> possible to express all this stuff in terms of GIMPLE (in fact, we
> already do, aside from PTRMEM_CST itself!), but we're essentially
> obfuscating information and then trying to get it back.
This is true of all the lowering we perform (loops->gotos, for example)
> Creating
> RECORD_TYPE instances to represent pointers-to-member-functions and then
> hoping that the middle end will scalarize the struct, fold all the tests
> for virtual-ness, dereference the virtual table entry, etc. seems like a
> lot of work to do de-virtualization.
> But, the information is in fact
> there, so I guess we could go that way.
>
We have no need for scalarization to occur to perform points-to *or*
type based devirtualization. Dereferencing is just a call, it is
always there anyway.
Folding is something we have to be doing anyway.
I just don't see this as as much work as you do. Both the type-based
that was posted before, and the points-to based one, are just not that
large in terms of code.
I also haven't necessarily said what Ollie has proposed is a bad idea.
I have simply said the way he has come up with what he proposed is
not the way we should go about this. It may turn out he has come up
with exactly the representation we want (though I doubt this, for
various reasons). The specification given also doesn't even explain
where/how these operations can occur in GIMPLE, and what they do other
than "a C++ something something".
Also given that someone already wrote a type-based devirtualizer that
worked fine, and i don't see how a points-to one is much work, I'd
like to see more justification for things like PTRMEM_PLUS_EXPR than
"hey, the C++ FE generates this internally".
So i have no real objection to either the type or the CST, I just want
to see semantics that are actually described in terms of our language
independent intermediate language, not in terms "what the C++ FE
does".
Example:
"* A pointer-to-member constant.
TREE_PTRMEM_CST_MEMBER is the _DECL for the member.
TREE_PTRMEM_CST_OFFSET takes on different interpretations depending on
the type of the member. If the member is NULL, it is ignored. If the
member is a FIELD_DECL it refers to the field offset. Otherwise, it refers
to the offset of the this pointer passed to methods. */"
No justification was given why there is a member and an offset, what
is allowed to be the _DECL for the member, why member is allowed to be
null, why member would sometimes be a FIELD_DECL, sometimes NULL, and
apparently sometimes neither NULL nor a FIELD_DECL, how to find the
this pointer offset refers to (only sometimes, apparently!), etc.
As I said, i'm really not necessarily opposed to seeing pointer to
members in the middle end, i'd just rather not see us underspecify it
and just take what the C++ FE currently does as "the word of the
lord".
> Michael and Danny have expressed opinions; does anyone else have one?
>
> Thanks,
>
> --
> Mark Mitchell
> CodeSourcery
> [EMAIL PROTECTED]
> (650) 331-3385 x713
>
