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 efficient optimization. COMPLEX_CST > and COMPLEX_TYPE are a good example. In theory, the middle end has > enough information to optimize complex arithmetic based solely on the > constituent operations on real and imaginary components, but it's > easier to deal with the complex number as an atomic unit. I agree. When I discussed this with Ollie, my feeling was that, yes, it's possible to express all this stuff in terms of GIMPLE (in fact, we already do, aside from PTRMEM_CST itself!), but we're essentially obfuscating information and then trying to get it back. Creating RECORD_TYPE instances to represent pointers-to-member-functions and then hoping that the middle end will scalarize the struct, fold all the tests for virtual-ness, dereference the virtual table entry, etc. seems like a lot of work to do de-virtualization. But, the information is in fact there, so I guess we could go that way. Michael and Danny have expressed opinions; does anyone else have one? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
