This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Migrate pointers to members to the middle end
On 8/9/07, Ollie Wild <aaw@google.com> wrote:
> On 8/9/07, Mark Mitchell <mark@codesourcery.com> wrote:
> > Daniel Berlin wrote:
> >
> > >> This is the source of my current woes, as this may involve virtual
> > >> function resolution, which can't be done with the information
> > >> currently available to the middle end.
> >
> > Ollie, IIRC, you posted an example where, together with your front-end
> > lowering patch (i.e., with the strategy that Daniel is advocating), we
> > don't do some optimization that we could in theory do. Have you worked
> > out why not? Perhaps that would shed some light on whether or not it's
> > tractable to recover this information from our current IR.
>
> The example I posted before indicated that the check to determine
> whether or not the member function is virtual wasn't optimized out.
> It didn't know that (fn_ptr & 1) == 0. That should be easy to fix by
> incorporating pointer alignment requirements in fold_binary().
>
> Offhand, I don't remember what happened with the various other cases,
> but my testing at the time wasn't particularly thorough. The feedback
> I've gotten so far seems overwhelmingly negative, so I think the next
> step is to revisit the lowering approach, exercise the hell out of it,
> and see what, if any, limitations pop up.
>
> Daniel mentioned something about a pre-existing type-based
> devirtualizer. I'd be interested to see how it works. From what I've
> been able to gleam from the GCC code, it seems that such an approach
> would need to hook back into the front end, which is a showstopper
> from an LTO perspective. It's entirely possible that I'm missing
> something, though.
See
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg00744.html
It only calls into the frontend to
1. Fold obj_type_ref_nodes (which would require *lowering* or defining
the semantics of it, not raising)
2. Determine what is a ctor/dtor (something we do not expose to the middle-end)
>
> Ollie
>