[Bug objc/101616] New: Objective-C frontend should not emit vtable/fixup messages (at least, not by default)

[Bug objc/101616] New: Objective-C frontend should not emit vtable/fixup messages (at least, not by default)

[mhjacobson at me dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101616

            Bug ID: 101616
           Summary: Objective-C frontend should not emit vtable/fixup
                    messages (at least, not by default)
           Product: gcc
           Version: 10.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: objc
          Assignee: unassigned at gcc dot gnu.org
          Reporter: mhjacobson at me dot com
  Target Milestone: ---

In 10.2.0, the Objective-C frontend (in NeXT v2 ABI mode) emits "fixup"
messages for all message sends.  Fixup messages are an abandoned optimization
in which the runtime specializes the message send routine to a fast vtable
lookup routine for a small set of common selectors.  (The set of common
selectors is hard-coded in the runtime.)  For other selectors, the fixup
message simply devolves into a normal message send, albeit with extra pointer
chasing.

The Apple runtime has not actually supported this optimization since OS X
Mountain Lion, as an inspection of the Mountain Lion [0] and Mavericks [1]
sources will confirm.  (Search for "fixupMessageRef".)  The Mavericks-and-later
runtimes still *deal* with fixup messages, but all callsites are treated as
non-optimized selectors.  Clang appears to have stopped emitting fixup messages
around 2010.

Furthermore, even when Clang *did* use fixup messages, it did so only for a
small set of selectors (that presumably tended to match the ones optimized by
the runtime).  By contrast, GCC simply uses them for all messages.

GCC should probably just stop emitting fixup messages calls entirely, but at
least it should only do so behind some driver flag.

[0]
https://opensource.apple.com/source/objc4/objc4-532/runtime/objc-runtime-new.mm.auto.html
[1]
https://opensource.apple.com/source/objc4/objc4-551.1/runtime/objc-runtime-new.mm.auto.html

[Bug objc/101616] Objective-C frontend should not emit vtable/fixup messages (at least, not by default)

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101616

Eric Gallager <egallager at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |egallager at gcc dot gnu.org,
                   |                            |iains at gcc dot gnu.org,
                   |                            |mikestump at comcast dot net

--- Comment #1 from Eric Gallager <egallager at gcc dot gnu.org> ---
cc-ing ObjectiveC maintainers

[Bug objc/101616] Objective-C frontend should not emit vtable/fixup messages (at least, not by default)

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101616

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED

--- Comment #2 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Matt Jacobson from comment #0)
> In 10.2.0, the Objective-C frontend (in NeXT v2 ABI mode) emits "fixup"
> messages for all message sends.

Please check 10.3, 11.(1,2rc) and master - I believe this is already fixed (and
back ported to 10.3).

I have not (yet) applied it to 9.x (so that would not appear until 9.5, if
done).

The changes are selective on the target OS version (since fixup messages _are_
emitted by the 'system' [i.e. last usable Xcode] compilers for earlier OS
versions).

So that 
gcc foo.m 
on a recent OS version should omit the fixup versions 
but with -mmacosx-version-min=10.5 the fixups versions should be emitted
(actually, with a few small changes as the OS version changes).

[Bug objc/101616] Objective-C frontend should not emit vtable/fixup messages (at least, not by default)

[mhjacobson at me dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101616

--- Comment #3 from Matt Jacobson <mhjacobson at me dot com> ---
Thanks -- I updated to 10.3.0 and looked into the changes.  (Sorry for
originally filing this against such an out-of-date compiler.)

As it happens, I'm targeting the NeXT v2 runtime, but I'm *not* actually
targeting Darwin.  So `flag_next_runtime` is just 1 for me--not an OS version
value like 100600 (`USE_FIXUP_BEFORE` / SnowLeopard).  (And I can't fake it via
arguments, AFAICT.)

I wonder if it would be reasonable to add a separate flag to disable (or
enable) fixup messages, such that the default value of the flag is controlled
by `-mmacosx-version-min` when targeting Darwin.

[Bug objc/101616] Objective-C frontend should not emit vtable/fixup messages (at least, not by default)

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101616

--- Comment #4 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Matt Jacobson from comment #3)

> As it happens, I'm targeting the NeXT v2 runtime, but I'm *not* actually
> targeting Darwin.  So `flag_next_runtime` is just 1 for me--not an OS
> version value like 100600 (`USE_FIXUP_BEFORE` / SnowLeopard).  (And I can't
> fake it via arguments, AFAICT.)

As I am sure you are aware - there is quite an amount of Mach-O-specific stuff
baked into the NeXT implementation.  However, for any system that supports
named sections it would seem reasonable to be able to support it.

Perhaps raise an 'emhancement' bug "Support NeXT runtime on system xxxxx" where
xxxxx is the system you want to support.

There are surely a number of changes that would be needed - and some that I've
most likely already thought about already (e.g. when thinking about what would
be needed to support ELF-based systems).

> I wonder if it would be reasonable to add a separate flag to disable (or
> enable) fixup messages, such that the default value of the flag is
> controlled by `-mmacosx-version-min` when targeting Darwin.

Darwin does three things - 
(a) for an invocation without 'mmacosx-version-min' it figures out the OS
version from the kernel.
(b) when the invocation includes mmacosx-version-min that overrides
(c) MACOSX_DEPLOYMENT_TARGET is also consulted to determine the target version
if there is no mmacosx-version-min.

The fine detail is that the *actual* code-gen produced by clang varies (in a
way that is incompatible with various versions of the linker) - so that we have
to take account of this and make sure we emit a suitable version for the OS
revision being targeted.

There are enough bits spare in the int representing flag_next_runtime that we
could arrange to have it indicate a non-Darwin implementation in some MSBs (and
then have the LSBs represent something different).

I suspect that this is just one of several changes that will be needed to
code-gen (thus the suggestion to have a tracking PR) and we should not be
adding more flags, but rather arranging to control the value of the
next_runtime flag and use that to determine the code-gen we want.