Am Freitag, den 10.04.2009, 09:22 +0200 schrieb Richard Guenther: > On Fri, Apr 10, 2009 at 3:41 AM, Ian Lance Taylor <i...@google.com> wrote: > > John Engelhart <john.engelh...@gmail.com> writes: > > > >> The easiest, and I think safest, course of action would be to add a > >> line in c_common_get_alias_set similar to the one I suggested. That > >> is, if it is a pointer to something that looks even remotely like an > >> objective-c "object", then just assume that it can alias anything. > >> > >> Any recommendations on what to do next? Filing a bug seems like the > >> step, I just wanted to see if I had missed something in my analysis of > >> the problem. > > > > Since you have a patch, you can just send it to gcc-patc...@gcc.gnu.org > > with a ChangeLog entry (see many existing messages on gcc-patches). It > > would be very good if you also had a test case to add to the testsuite. > > Note that I think that ObjC should be fine (assuming it is a completely > statically typed language) if it properly maintains BINFO records. At least > this is how it works in C++, see record_component_aliases in alias.c. > > If ObjC is really dynamically typed then TBAA is indeed doomed.
ObjC is a dynamically typed language with many design / implementation patterns relying on dynamic typing (NSProxy, NSDistantObject, EOFault just to name a few). Also the language the @defs construct to allow access to the underlying structure to allow certain efficient implementations. Also when implementing class clusters, casting is often used to access instance variables of objects that are assumed to have a certain layout due to certain dynamic predicates. I think most ObjC projects currently use --no-strict-aliasing by default (I know GNUstep related projects do). But it would be great if that could be dropped so that plain C code could take advantage of the potential optimizations, yet I have no real concept of whether any performance gain would be measurable within ObjC itself. Cheers, David
