This patch adds a new ".alt_entry" assembly directive for Mach-O and uses it for global aliases with non-zero GEP offsets. The directive name is based on the idea of it being an alternate entry point into the middle of an object. Akira Hatanaka developed this patch in consultation with John McCall and Nick Kledzik. This code is currently used for Swift but it is a general feature that I think we should support in trunk.
Diff Detail
Event Timeline
This is missing a test from .s to .o.
In the object file, what is the difference that a .alt_entry has? Also, it seems odd to make the codegen decision based on the expression being binary. Would a llvm optimization removing a +0 change the semantics by dropping the .alt_entry?
Two bugs you might want to be aware of in relation to this:
The object files have a new SF_AltEntry flag to distinguish symbols that do not start a new atom. ld64 has had support for that for a while now.
I suppose we could narrow the check for a binary expression to check for a non-zero offset. I'm not sure it is necessary, though. If the offset is zero, the linker doesn't need to know whether it is a new atom or an alternate entry. Is there a particular case that you're concerned about there?
The bugs you cite are definitely related. It seems to me like they are at least in part due to the lack of this feature.
You're right about the need for a test of the object files. I'll see if I can get something.