[PATCH] D17854: add .alt_entry assembly directive for Mach-O

[Bob Wilson via llvm-commits]

> On Mar 3, 2016, at 6:41 PM, Bob Wilson via llvm-commits <llvm-commits at lists.llvm.org> wrote:
> 
> 
>> On Mar 3, 2016, at 12:31 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
>> 
>> On 3 March 2016 at 15:20, Bob Wilson <bob.wilson at apple.com> wrote:
>>> bob.wilson added a comment.
>>> 
>>> 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.
>> 
>> OK, so the idea is that the
>> 
>> .alt_entry foo
>> 
>> directive causes foo to have the SF_AltEntry flag which tells the
>> linker that foo doesn't define an atom.
>> 
>> Another possibility would be to close pr25381 as working as intended and have
>> 
>> foo = bar
>> and
>> foo = bar + 42
>> 
>> not start new atoms and produce SF_AltEntry (maybe dropping it for
>> offset 0 as an optimization).
>> 
>> This would have the advantage of not needing a new directive and
>> avoiding having to diagnose things like
>> 
>> foo:
>> .alt_entry foo
> 
> I’m open to that. I checked with the Swift team, and they’re generating global aliases in IR without relying on the assembly syntax.
> 
> + Nick, Lang, and Louis
> Do you have an opinion on this from the linker’s perspective?

Oops. It looks like I only CC’ed Lang. Adding Nick and Louis for real.

> 
> Here’s a test that Akira wrote for the assembly-to-object part.
> <altent.s>