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

[Eric Christopher via llvm-commits]

On Mon, Feb 5, 2018 at 6:19 PM Ryan Prichard via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> 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 is less of an issue because we release in lockstep here.


> 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.
>
>
Agreed.


> 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.
>
>
Nothing comes to mind.

-eric


> -Ryan
>
> _______________________________________________
> 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/20180206/81e6426d/attachment.html>