[PATCH] D42720: [CodeGen] Switch non-SJLJ EH encoding to uleb128

[Ryan Prichard via llvm-commits]

On Mon, Feb 5, 2018 at 5:12 PM, Rafael Avila de Espindola <
rafael.espindola at gmail.com> wrote:

> Ryan Prichard via Phabricator via llvm-commits
> <llvm-commits at lists.llvm.org> writes:
>
> > rprichard created this revision.
> > Herald added subscribers: llvm-commits, JDevlieghere, javed.absar,
> aprantl.
> >
> > With this commit, LLVM emits a DWARF EH table using GCC-style assembly by
> > default. Offsets in the EH table (code offsets in the call site table,
> > the call site table size, and the offset to TTBase) are calculated in the
> > assembler rather than in the compiler. Doing so allows switching the
> > encoding of code offsets in the call site table from udata4 to uleb128,
> > which can reduce the size of the EH table by half.
> >
> > This behavior is on by default. The old behavior can be restored with
> > -mllvm -layout-eh-table-in-assembler=0.
>
> Do we really need to keep the old behavior around? What depends on it?
>

As far as I know, the old behavior isn't needed. I'd be happy to remove it.

One possibility: a combination of a new Clang and an old LLVM assembler
could hit the infinite loop (PR35809). This configuration seems rare to me:
macOS is the only system I know of where '/usr/bin/as' is the LLVM
assembler. As long as the macOS compiler and assembler are the same LLVM
version, though, there's no problem. Clang also defaults to the integrated
assembler, which avoids the problem.

Otherwise, maybe there are esoteric assemblers that don't support uleb128
directives (or *do* support them, but hit the infinite loop problem)? I
don't know of any in particular.

-Ryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180205/fe6644d1/attachment.html>