This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fwd: Objective-C and C99 strict aliasing


Am Freitag, den 10.04.2009, 09:22 +0200 schrieb Richard Guenther:
> On Fri, Apr 10, 2009 at 3:41 AM, Ian Lance Taylor <iant@google.com> wrote:
> > John Engelhart <john.engelhart@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-patches@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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]