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 turn out he has come up > > with exactly the representation we want (though I doubt this, for > > various reasons). The specification given also doesn't even explain > > where/how these operations can occur in GIMPLE, and what they do other > > than "a C++ something something". > > > > Also given that someone already wrote a type-based devirtualizer that > > worked fine, and i don't see how a points-to one is much work, I'd > > like to see more justification for things like PTRMEM_PLUS_EXPR than > > "hey, the C++ FE generates this internally". > > OK. It sounds like I need to go into a lot more detail. The new > nodes I've proposed aren't actually motivated by the C++ front end, > but rather by a consideration of the semantics dictated by the C++ > standard. Naturally, this gives rise to some similarity, but for > instance, there is no PTRMEM_PLUS_EXPR in the C++ front end, and my > definition of PTRMEM_CST disagrees with the current node of the same > name. > > Let's walk through them:
[...] Just to throw in something late from the side. Can you try to model things in such a way that representing TLS accesses on the tree level would be possible with whatever new infrastructure you come up with? (It's the only thing we keep libcalls for if I remember correctly) Thx, Richard.
