[PATCH] Get TargetOptions after parseCodeGenDebugOptions in LTO

[Tom Roeder]

On Tue, Jun 17, 2014 at 12:43 PM, Rafael Espíndola
<rafael.espindola at gmail.com> wrote:
> So, from the gold api perspective you can you the extra options as
> soon as the loop in onload is done.

I see. This means the option parsing code in LTOCodeGenerator would
have to be pushed earlier too, probably into the lto_module_create
code, guarded by the parsedOptions flag.

I can make this and the other changes as a temporary fix until
tools/gold is rewritten to use lib/LTO. What do you think?

>
> Maybe the correct change is for LTOModule to not require a target and
> have on be passed down as needed? This would be a somewhat big change.
> Since the C api is stable, this would be easier to do once tools/gold
> is using lib/LTO directly (which I hope to do really soon now).
>
> Also, do you have a testcase where this makes a difference?

I don't have a testcase for LLVM, obviously, since this has to do with
LLVMgold.so, but I do for clang -flto. Consider the following test
file

target triple = "x86_64-unknown-linux-gnu"
define i32 @g(i32 %a) unnamed_addr jumptable {
  ret i32 %a
}

define i32 @f() unnamed_addr jumptable {
  ret i32 0
}

define i32 @main() {
  ret i32 0
}

Run the following command

clang -flto -Wl,--plugin-opt=-jump-table-type=arity
-Wl,--plugin-opt=-disable-opt test.ll

This should lead to two jump tables, and there should be the symbols
__llvm_jump_instr_table_1_1 and __llvm_jump_instr_table_0_1 in the
resulting executable. Instead, there's only one jump table (the
default "single" jumptable type), hence the symbols
__llvm_jump_instr_table_0_1 and __llvm_jump_instr_table_0_2.

With my patch, LTOCodeGenerator gets the right TargetOptions and
passed them down to LLVMTargetMachine, which in turn gives the right
value to JumpInstrTables.

Also, I just remembered I forgot to add something else to the patch:
there are two places that handle TargetOptions, and they've gone out
of sync: one is a static method in
include/llvm/CodeGen/CommandFlags.h, and the other is a member of
LTOCodeGenerator.cpp. Here's the patch with that bit added, just to
show where it is. I suspect the right fix in this case is to merge
those two methods, so they can't go out of sync anymore.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lto_options.patch
Type: text/x-patch
Size: 1795 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140617/7f54c3ae/attachment.bin>