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: Regression for trunk on i686-pc-linux-gnu


    Why exactly did allowing INDIRECT_REF in is_gimple_addr_expr_arg make
    this test pass?

I have no clue.  I haven't tried to analyze that yet and am not sure where
to look.

    I don't doubt that.  What I doubt is whether it's reasonable at all.
    If this only occurs during gimplification, why not just strip
    INDIRECT_REF when you build the call to memcpy?

Mostly because it means looking for it.  And you might have something
like a VIEW_CONVERT_EXPR in between.   So it's not a trivial test and
it would have to be in a number of places.

My feeling would be to standardize this with some common code, but
even then you need to allow INDIRECT_REF in something that's
going to be *fed* to the common code, and that's my recollection of
what's happening here.

    The reason why we support folding of *&VAR is because it exposes
    optimization opportunities.  I see no such advantage here.

I don't follow.  If folding *&VAR to VAR creates optimization opportunities,
doesn't folding &*VAR to VAR do exactly the same?

    Why not just pass the operand to INDIRECT_REF?  After all, it is a
    pointer, isn't it?

That's what ends up happening, but it's this folding that makes it happen.


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