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

[Nick Kledzik via llvm-commits]

> On Mar 3, 2016, at 6:41 PM, Bob Wilson <bob.wilson at apple.com> 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).
That may make compiler generated assembly file simpler, but I think hand written files would not use the = syntax.  They’d use:

_bzero:
    	mov %rdx, %rsi
	mov %rsi, 0
	.alt_entry _memset
_memset:
	blah
	blah

The idea is you have one function that falls into the next, and you want to tell the linker they should not be moved apart.  To use the = syntax, you’d need to figure out how many bytes are in the first chunk of code. Using a regular label seems more natural.

-Nick



>> 
>> 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?
> 
> Here’s a test that Akira wrote for the assembly-to-object part.
> <altent.s>