This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
[RFC] Migrate pointers to members to the middle end
- From: "Ollie Wild" <aaw at google dot com>
- To: "GCC List" <gcc at gcc dot gnu dot org>
- Date: Tue, 7 Aug 2007 14:04:19 -0700
- Subject: [RFC] Migrate pointers to members to the middle end
Hi,
In response to a suggestion from Mark Mitchell, I've been attempting
to migrate pointers to members to the GCC middle end. The goal of
this is twofold: (a) to enable conversion of pointer to member
dereferences to direct function calls and member accesses when
analysis determines this is unambiguous and (b) to obsolete the need
for the expand_constant language hook.
Under my current approach, I've added the following new nodes to gcc/tree.def:
/* A C++ pointer-to-member type.
The TREE_TYPE field is the member type.
The TYPE_PTRMEM_BASETYPE points to the node for the class to which the
member belongs. */
DEFTREECODE (PTRMEM_TYPE, "ptrmem_type", tcc_type, 0)
/* 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. */
DEFTREECODE (PTRMEM_CST, "ptrmem_cst", tcc_constant, 0)
/* Pointer to member addition. This is used in type conversions to adjust the
pointer to member offset. The first operand is a pointer to
member, and the
second operand is an integer of type sizetype. */
DEFTREECODE (PTRMEM_PLUS_EXPR, "ptrmem_plus_expr", tcc_binary, 2)
/* A C++ pointer-to-member dereference.
Operand 0 is a class expression.
Operand 1 is a pointer-to-member. */
DEFTREECODE (PTRMEM_REF, "ptrmem_ref", tcc_reference, 2)
I then modify the C++ front end to instantiate the new nodes, expand
them inside expand_expr_real_1 and output_constant, and perform
folding in the various fold-const functions.
However, pointers to virtual functions are turning out to be
problematic. As far I can tell, the middle end has no concept of
virtual functions and virtual function tables: they appear to be
implemented solely in the C++ front end. This suggests that a
migration of the virtual function machinery is a necessary
precondition to pointer to member migration.
Some questions for the GCC community:
1. Is pointer to member migration worthwhile? Can other languages
besides C++ benefit from this?
2. Do the tree nodes I've discussed make sense? Is there a better
way to represent pointer to member objects and operations?
3. What can I do to handle virtual functions? Is it possible to
handle this without migrating virtual functions to the middle end?
4. Is a migration of virtual functions and virtual function tables
required? Are the various language implementations sufficiently
similar to be handled by a common infrastructure?
Any and all feedback is appreciated.
Thanks,
Ollie