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 <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.

> >There are also simple variant without the offset that would probably
> >also worth folding even if number of statements don't decrease
> >(ie  (partent_type *)ptr into &ptr->parent)
> 
> I think it's always worth removing a cast in favor of addressing the
> right component.  Though if we succeed in creating a single
> base + offset memory reference tree this work will be a wash if
> the address is dereferenced...

Yep, however I am bit more interested in cases this is not dereferenced
to help IPA optimizations Martin is working on.
> 
> >Looks like there are a lot more cases than I would like ;(
> >However if we fold this my testcase (with few iostreams and multiple
> >inheritance) would be mostly NOP_EXPR free.
> 
> It's worth fixing more testcases if they actually happen in real code - at
> least that is what I have been doing in handling the (T*)&a->x.y to
> &a->x case.

I am testing two extra cases and then I am apparently out of simple
C++ testcases.  I will probably take a look on few selected functions of
some bigger C++ body, but since my testcase does IO streams, I guess I
got the most common cases already.

Honza
> 
> Richard.


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