This is the mail archive of the gcc-patches@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: Convert (type *)&A into &A->field_of_type_and_offset_0.


> On 4/9/07, Jan Hubicka <hubicka@ucw.cz> wrote:
> >> On 4/9/07, Jan Hubicka <jh@suse.cz> wrote:
> >> >>
> >> >> This is ok if you also add the testcase (it's missing from the
> >> >ChangeLog).
> >> >
> >> >I plan so, I am usually writting changelogs for testcases at time of
> >> >comitting them (so name is fixed), but I can change the procedure.
> >> >
> >> >There is comment in from of maybe_fold_offset_to_component_ref:
> >> >
> >> >/* A subroutine of fold_stmt_r.  Attempts to fold *(S+O) to S.X.
> >> >   BASE is a record type.  OFFSET is a byte displacement.  ORIG_TYPE
> >> >   is the desired result type.  */
> >> >/* ??? This doesn't handle class inheritance.  */
> >> >
> >> >Any idea what the comment about inheritance is about?
> >>
> >> No idea.
> >> >          {
> >> >            D.29475 = (struct BetterTrgl *) 4;
> >> >            D.29476 = this + D.29475;
> >> >            D.29477 = (struct Triangle *) D.29476;
> >> >          ...
> >> >
> >> >The cast on 4 seems a bit curious, I would expect it to be already
> >> >folded into INTEGER_CST.
> >>
> >> Yes, it looks like somebody forgets to fold this.  (Inlining?)
> >
> >It is pre-inlining (already in generic dump), probably it is result of
> >some gimplification, I will try to dig into.  In general I would however
> >preffer middle end to clean up this anyway.
> 
> Uh, no.  We have to keep the invariant that trees are always in folded
> form.
Hi,
I've found source of my unfolded statement:

Index: gcc/cp/class.c
===================================================================
--- gcc/cp/class.c	(revision 123674)
+++ gcc/cp/class.c	(working copy)
@@ -522,10 +522,10 @@ convert_to_base_statically (tree expr, t
       pointer_type = build_pointer_type (expr_type);
       expr = build_unary_op (ADDR_EXPR, expr, /*noconvert=*/1);
       if (!integer_zerop (BINFO_OFFSET (base)))
-	  expr = build2 (PLUS_EXPR, pointer_type, expr,
-			 build_nop (pointer_type, BINFO_OFFSET (base)));
-      expr = build_nop (build_pointer_type (BINFO_TYPE (base)), expr);
-      expr = build1 (INDIRECT_REF, BINFO_TYPE (base), expr);
+	  expr = fold_build2 (PLUS_EXPR, pointer_type, expr,
+			      fold_convert (pointer_type, BINFO_OFFSET (base)));
+      expr = fold_convert (build_pointer_type (BINFO_TYPE (base)), expr);
+      expr = build_fold_indirect_ref (expr);
     }
 
   return expr;

I am testing the patch, but it seems like it was unfolded for a purpose.
Mark, can you enlighten me why this expression is not folded?
The (type)integer_cst seems particularly silly in such a common
construct.

Honza


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