On 8/9/07, Ollie Wild <[EMAIL PROTECTED]> wrote: > On 8/9/07, Mark Mitchell <[EMAIL PROTECTED]> 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 >
