On 8/9/07, Ollie Wild <[EMAIL PROTECTED]> wrote:
> On 8/8/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> > I also haven't necessarily said what Ollie has proposed is a bad idea.
> > I have simply said the way he has come up with what he proposed is
> > not the way we should go about this. It may
> "Dan" == Daniel Berlin <[EMAIL PROTECTED]> writes:
Dan> Just to be clear, we *already* have the class hierarchies in the
Dan> middle end.
Dan> They have been there for a few years now :)
Good point, thanks.
I don't think that is enough though, because I don't think the BINFO
slots mean th
Ollie Wild wrote:
> 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 o
Hi,
On Thu, 9 Aug 2007, Tom Tromey wrote:
Michael> Yes, devirtualization. But I wonder if you really need class
Michael> hierarchies for this (actually I'm fairly sure you don't).
However, I'm not sure I agree with the above assertion. Specifically,
for Java I think it is sometimes possible
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 availab
On 8/9/07, Joe Buck <[EMAIL PROTECTED]> wrote:
> On Thu, Aug 09, 2007 at 02:29:28PM -0600, Tom Tromey wrote:
> > Also in Java it is possible to devirtualize calls in some situations
> > where only a bound on the type is known. For instance at a call site
> > we might know that all possible targets
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
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 t
On Thu, Aug 09, 2007 at 02:11:34PM -0700, Joe Buck wrote:
> On Thu, Aug 09, 2007 at 02:29:28PM -0600, Tom Tromey wrote:
> > Also in Java it is possible to devirtualize calls in some situations
> > where only a bound on the type is known. For instance at a call site
> > we might know that all possi
On Thu, Aug 09, 2007 at 02:29:28PM -0600, Tom Tromey wrote:
> Also in Java it is possible to devirtualize calls in some situations
> where only a bound on the type is known. For instance at a call site
> we might know that all possible targets are derived from a class where
> the virtual method is
> "Michael" == Michael Matz <[EMAIL PROTECTED]> writes:
Michael> Yes, devirtualization. But I wonder if you really need class
Michael> hierarchies for this (actually I'm fairly sure you don't).
I'm generally in favor of what you talked about in this note and
others, and also Danny's overall
> "Ollie" == Ollie Wild <[EMAIL PROTECTED]> writes:
Ollie> 1. Is pointer to member migration worthwhile? Can other languages
Ollie> besides C++ benefit from this?
Not Java. You might ask Andrea about CLR though.
Ollie> 4. Is a migration of virtual functions and virtual function tables
Ol
On 8/8/07, Ollie Wild <[EMAIL PROTECTED]> wrote:
> On 8/8/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> > I also haven't necessarily said what Ollie has proposed is a bad idea.
> > I have simply said the way he has come up with what he proposed is
> > not the way we should go about this. It may
On 8/8/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> I also haven't necessarily said what Ollie has proposed is a bad idea.
> I have simply said the way he has come up with what he proposed is
> not the way we should go about this. It may turn out he has come up
> with exactly the representation
On 8/8/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Ollie Wild wrote:
> > On 8/8/07, Michael Matz <[EMAIL PROTECTED]> wrote:
>
> Ollie, thanks for patiently trying out different approaches.
>
> > I think the primary purpose of the middle end is to provide a
> > representation which captures the s
Ollie Wild wrote:
> On 8/8/07, Michael Matz <[EMAIL PROTECTED]> wrote:
Ollie, thanks for patiently trying out different approaches.
> I think the primary purpose of the middle end is to provide a
> representation which captures the semantics of a program at a
> sufficiently high level to enable e
On 8/8/07, Michael Matz <[EMAIL PROTECTED]> wrote:
> So those tree expressions would live throughout the middle-end and only
> then become lowered to RTL directly? I'm not sure that's worthwhile.
> E.g. I'm not sure why there's a need to really get rid of the
> expand_constant langhook. It's only
Hi,
On Thu, 8 Aug 2007, Ian Lance Taylor wrote:
those whose runtime type can be any derived one) can not. E.g. I
wouldn't try to model the inheritance relationship.
There is some advantage to knowing class heirarchy relationships in LTO.
Some C++ programs implement different virtual subclas
On 08 Aug 2007 17:36:43 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> Michael Matz <[EMAIL PROTECTED]> writes:
>
> > If you were to implement something like virtual functions into the middle
> > end, it should be expressed in a fairly low level way IMHO. E.g. a
> > virtual table simply bein
Michael Matz <[EMAIL PROTECTED]> writes:
> If you were to implement something like virtual functions into the middle
> end, it should be expressed in a fairly low level way IMHO. E.g. a
> virtual table simply being a vector of pointers to function decls (which
> we can express already just fin
Hi,
On Tue, 7 Aug 2007, Ollie Wild wrote:
> In response to a suggestion from Mark Mitchell, I've been attempting to
> migrate pointers to members to the GCC middle end. The goal of this is
> twofold: (a) to enable conversion of pointer to member dereferences to
> direct function calls and mem
Hi,
In response to a suggestion from Mark Mitchell, I've been attempting
to migrate pointers to members to the GCC middle end. The goal of
this is twofold: (a) to enable conversion of pointer to member
dereferences to direct function calls and member accesses when
analysis determines this is unam
22 matches
Mail list logo
