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

[Lang Hames via llvm-commits]

Hi Nick,

I think Rafael had in mind that we'd write something like:

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

Which would be more livable for people hand-writing code. I like this
because, if workable, it'd provide a solution to http://llvm.org/PR25381 at
the same time.

- Lang.

On Mon, Mar 7, 2016 at 6:00 PM, Nick Kledzik via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

>
> > 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>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160307/2e203e29/attachment.html>