Closed Bug 1457482 Opened 7 years ago Closed 6 years ago

Create a Linux Clang ThinLTO Build

Categories

(Firefox Build System :: General, defect)

Product:
Firefox Build System
Component:
General
Version:
3 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(firefox62 fixed)

Status:
RESOLVED FIXED
Milestone:
mozilla62
Tracking Flags:
Tracking Status
firefox62 --- fixed

People

(Reporter: tjr, Assigned: tjr)

References

(Blocks 2 open bugs)

Details

Attachments

(4 files, 1 obsolete file)

Bug 1457482 Add lld to the clang-6-pre-linux64 toolchain for use in the LTO build
59 bytes, text/x-review-board-request
glandium
: review+
Details
Bug 1457482 Add an LTO Build Target
59 bytes, text/x-review-board-request
glandium
: review+
Details
Bug 1457482 Add --enable-lto that turns on LTO
59 bytes, text/x-review-board-request
glandium
: review+
Details
Bug 1457482 Correct elfhack's LTO detection to handle -flto=thin
59 bytes, text/x-review-board-request
glandium
: review+
Details
Clang LTO is required for Control Flow Integrity. This bug tracks creating an --enable-lto flag for Linux. See Also: Bug 1448980 which tracks it for Windows.
Depends on: 1457483
Comment on attachment 8971636 [details] Bug 1457482 Add an LTO Build Target https://reviewboard.mozilla.org/r/240394/#review246208 ::: build/unix/mozconfig.lto:21 (Diff revision 2) > +# Mandatory options that were copied from ASan builds > +export MOZ_DEBUG_SYMBOLS=1 > +ac_add_options --enable-debug-symbols > +ac_add_options --disable-install-strip > +ac_add_options --disable-jemalloc > +ac_add_options --disable-crashreporter (Drive-by) A bunch of these options are specific to ASan and shouldn't be necessary for a more vanilla clang build. --disable-jemalloc and --disable-crashreporter definitely aren't required. I am semi-sure that --disable-profiling can go too. And I believe debug symbols are on by default nowadays.
Okay, I think this is good to go. glandium, I figured you'd probably have thoughts, but I can redirect review if you wish. In contrast to the Windows --enable-lto bug; I made --enable-lto default to thin since it's difficult to do a full LTO build. It times out on TC, and we may not have enough RAM on the builders...
Comment on attachment 8971635 [details] Bug 1457482 Add lld to the clang-6-pre-linux64 toolchain for use in the LTO build https://reviewboard.mozilla.org/r/240392/#review246622 ::: build/build-clang/clang-6-pre-linux64-lto.json:9 (Diff revision 4) > + "build_libcxx": true, > + "build_type": "Release", > + "assertions": false, > + "llvm_repo": "https://llvm.org/svn/llvm-project/llvm/trunk", > + "clang_repo": "https://llvm.org/svn/llvm-project/cfe/trunk", > + "lld_repo": "https://llvm.org/svn/llvm-project/lld/trunk", So the only difference with clang-6-pre-linux64.json is this line. Why not add it there?
Attachment #8971635 - Flags: review?(mh+mozilla)
Comment on attachment 8971636 [details] Bug 1457482 Add an LTO Build Target https://reviewboard.mozilla.org/r/240394/#review246624 Generally speaking it would be better to source the "normal" mozconfig, and add overrides, rather than duplicate the whole thing. I'm also not particularly convinced we need debug+lto builds. ::: browser/config/mozconfigs/linux64/debug-lto:8 (Diff revision 5) > + > +. $topsrcdir/build/mozconfig.stylo > + > +. $topsrcdir/build/unix/mozconfig.lto > + > +ac_add_options --disable-elf-hack why? ::: testing/mozharness/configs/builds/releng_sub_linux_configs/64_lto_tc.py:23 (Diff revision 5) > + 'TOOLTOOL_CACHE': '/builds/tooltool_cache', > + 'TOOLTOOL_HOME': '/builds', > + 'MOZ_CRASHREPORTER_NO_REPORT': '1', > + 'LC_ALL': 'C', > + ## 64 bit specific > + 'PATH': '/usr/local/bin:/usr/lib64/ccache:/bin:\ we should stop cargo culting useless paths. Things under /tools, and the ccache directory are useless. As a matter of fact, the default PATH should just work, so there should be no need to set one at all.
Attachment #8971636 - Flags: review?(mh+mozilla)
Comment on attachment 8971637 [details] Bug 1457482 Add --enable-lto that turns on LTO https://reviewboard.mozilla.org/r/240396/#review246628 ::: build/moz.configure/toolchain.configure:1308 (Diff revision 6) > + help='Enable LTO') > + > + > +@depends('--enable-lto', target) > +def lto(value, target): > + if value and target.kernel != 'Linux': I don't see why this should be limited to Linux. It's more of a compiler thing than a target thing. ::: build/moz.configure/toolchain.configure:1316 (Diff revision 6) > + flags = [] > + ldflags = [] > + > + # Until Bug 1457168 is fixed, I have to hardcode -fuse-ld=lld here > + if len(value) and value[0].lower() == 'full': > + flags.append("-fuse-ld=lld") You're pretty much assuming LTO = clang, but GCC can do lto too, and doesn't need lld for that. ::: build/moz.configure/toolchain.configure:1382 (Diff revision 6) > flags.append("-D_FORTIFY_SOURCE=2") > js_flags.append("-U_FORTIFY_SOURCE") > js_flags.append("-D_FORTIFY_SOURCE=2") > > # If ASAN _is_ on, undefine FOTIFY_SOURCE just to be safe > - if asan: > + if asan or lto: why? ::: build/moz.configure/toolchain.configure:1389 (Diff revision 6) > js_flags.append("-U_FORTIFY_SOURCE") > > # fstack-protector ------------------------------------ > # Enable only if --enable-hardening is passed and ASAN is > # not on as ASAN will catch the crashes for us > - if hardening_flag and compiler_is_gccish and not asan: > + if hardening_flag and compiler_is_gccish and not asan and not lto: why? ::: build/unix/mozconfig.lto:20 (Diff revision 6) > if [ -e "$topsrcdir/gcc/bin/ld" ]; then > export CC="$CC -B $topsrcdir/gcc/bin" > export CXX="$CXX -B $topsrcdir/gcc/bin" > fi > > +ac_add_options --enable-lto Let me ask this bluntly: what's the point of having a configure flag if you also need to set extra environment variables to use llvm-* tools? Why not just set CFLAGS/CXXFLAGS to add -flto?
Attachment #8971637 - Flags: review?(mh+mozilla)
Attachment #8971705 - Flags: review?(core-build-config-reviews) → review?(nfroyd)
Comment on attachment 8971705 [details] Bug 1457482 Add Tests for LTO Opt https://reviewboard.mozilla.org/r/240474/#review246710 I don't think there's anything objectionable about the code here. But have you checked with TC/Releng folks about adding another set of tests and what that does to capacity expectations and the like?
Attachment #8971705 - Flags: review?(nfroyd) → review+
Comment on attachment 8971635 [details] Bug 1457482 Add lld to the clang-6-pre-linux64 toolchain for use in the LTO build https://reviewboard.mozilla.org/r/240392/#review246622 > So the only difference with clang-6-pre-linux64.json is this line. Why not add it there? Doing so would also fix bug 1461820 (at least for clang-6-pre).
(In reply to Mike Hommey [:glandium] from comment #21) > Comment on attachment 8971636 [details] > Bug 1457482 Add an LTO Build Target > > https://reviewboard.mozilla.org/r/240394/#review246624 > > Generally speaking it would be better to source the "normal" mozconfig, and > add overrides, rather than duplicate the whole thing. Will change. > I'm also not particularly convinced we need debug+lto builds. > ::: browser/config/mozconfigs/linux64/debug-lto:8 > (Diff revision 5) > > + > > +. $topsrcdir/build/mozconfig.stylo > > + > > +. $topsrcdir/build/unix/mozconfig.lto > > + > > +ac_add_options --disable-elf-hack > > why? It turns out elfhack can't handle the output of LTO builds. Even building test-array.c and tryign to hack it, we error: /builds/worker/workspace/build/src/obj-firefox/build/unix/elfhack/elfhack -b -f test-array.so test-array.so: terminate called after throwing an instance of 'std::runtime_error' what(): Sections overlap Makefile:17: recipe for target 'test-array.so' failed readelf --sections test-array.so There are 35 section headers, starting at offset 0xd628: Section Headers: [Nr] Name Type Address Offset Size EntSize Flags Link Info Align [ 0] NULL 0000000000000000 00000000 0000000000000000 0000000000000000 0 0 0 [ 1] .rodata PROGBITS 0000000000000270 00000270 00000000000001fe 0000000000000000 AMS 0 0 16 [ 2] .note.gnu.build-i NOTE 0000000000000470 00000470 0000000000000018 0000000000000000 A 0 0 4 [ 3] .dynsym DYNSYM 0000000000000488 00000488 0000000000000108 0000000000000018 A 8 1 8 [ 4] .gnu.version VERSYM 0000000000000590 00000590 0000000000000016 0000000000000002 A 3 0 2 [ 5] .gnu.version_r VERNEED 00000000000005a8 000005a8 0000000000000030 0000000000000000 A 8 1 4 [ 6] .gnu.hash GNU_HASH 00000000000005d8 000005d8 0000000000000054 0000000000000000 A 3 0 8 [ 7] .hash HASH 000000000000062c 0000062c 0000000000000060 0000000000000004 A 3 0 4 [ 8] .dynstr STRTAB 000000000000068c 0000068c 00000000000000b6 0000000000000000 A 0 0 1 [ 9] .rela.dyn RELA 0000000000000748 00000748 0000000000003af8 0000000000000018 A 3 0 8 [10] .rela.plt RELA 0000000000004240 00004240 0000000000000018 0000000000000018 A 3 0 8 [11] .eh_frame_hdr PROGBITS 0000000000004258 00004258 0000000000000024 0000000000000000 A 0 0 1 [12] .eh_frame PROGBITS 0000000000004280 00004280 0000000000000080 0000000000000000 A 0 0 8 [13] .text PROGBITS 0000000000005000 00005000 0000000000003027 0000000000000000 AX 0 0 16 [14] .plt PROGBITS 0000000000008030 00008030 0000000000000020 0000000000000000 AX 0 0 16 [15] .data PROGBITS 0000000000009000 00009000 0000000000001380 0000000000000000 WA 0 0 16 [16] .got.plt PROGBITS 000000000000a380 0000a380 0000000000000020 0000000000000000 WA 0 0 8 [17] .tbss NOBITS 000000000000a3a0 0000a3a0 0000000000001010 0000000000000000 WAT 0 0 16 [18] .init_array INIT_ARRAY 000000000000b000 0000b000 0000000000000010 0000000000000000 WA 0 0 16 [19] .dynamic DYNAMIC 000000000000b010 0000b010 00000000000001a0 0000000000000010 WA 8 0 8 [20] .got PROGBITS 000000000000b1b0 0000b1b0 0000000000000018 0000000000000000 WA 0 0 8 [21] .bss NOBITS 000000000000c000 0000b1c8 0000000000000010 0000000000000000 WA 0 0 8 [22] .debug_str PROGBITS 0000000000000000 0000b1c8 000000000000044d 0000000000000000 MS 0 0 1 [23] .debug_loc PROGBITS 0000000000000000 0000b615 0000000000000076 0000000000000000 0 0 1 [24] .debug_abbrev PROGBITS 0000000000000000 0000b68b 00000000000000ed 0000000000000000 0 0 1 [25] .debug_info PROGBITS 0000000000000000 0000b778 00000000000008db 0000000000000000 0 0 1 [26] .debug_ranges PROGBITS 0000000000000000 0000c053 0000000000000040 0000000000000000 0 0 1 [27] .debug_macinfo PROGBITS 0000000000000000 0000c093 0000000000000001 0000000000000000 0 0 1 [28] .debug_pubnames PROGBITS 0000000000000000 0000c094 00000000000004d1 0000000000000000 0 0 1 [29] .debug_pubtypes PROGBITS 0000000000000000 0000c565 0000000000000056 0000000000000000 0 0 1 [30] .comment PROGBITS 0000000000000000 0000c5bb 0000000000000052 0000000000000000 MS 0 0 1 [31] .debug_line PROGBITS 0000000000000000 0000c60d 0000000000000274 0000000000000000 0 0 1 [32] .symtab SYMTAB 0000000000000000 0000c888 00000000000008b8 0000000000000018 34 83 8 [33] .shstrtab STRTAB 0000000000000000 0000d140 000000000000015f 0000000000000000 0 0 1 [34] .strtab STRTAB 0000000000000000 0000d29f 0000000000000383 0000000000000000 0 0 1 readelf -d test-array.so Dynamic section at offset 0xb010 contains 25 entries: Tag Type Name/Value 0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0] 0x0000000000000001 (NEEDED) Shared library: [libstdc++.so.6] 0x0000000000000001 (NEEDED) Shared library: [libm.so.6] 0x0000000000000001 (NEEDED) Shared library: [libgcc_s.so.1] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] 0x000000000000000e (SONAME) Library soname: [test-array.so] 0x0000000000000007 (RELA) 0x748 0x0000000000000008 (RELASZ) 15096 (bytes) 0x0000000000000009 (RELAENT) 24 (bytes) 0x000000006ffffff9 (RELACOUNT) 624 0x0000000000000017 (JMPREL) 0x4240 0x0000000000000002 (PLTRELSZ) 24 (bytes) 0x0000000000000003 (PLTGOT) 0xa380 0x0000000000000014 (PLTREL) RELA 0x0000000000000006 (SYMTAB) 0x488 0x000000000000000b (SYMENT) 24 (bytes) 0x0000000000000005 (STRTAB) 0x68c 0x000000000000000a (STRSZ) 182 (bytes) 0x000000006ffffef5 (GNU_HASH) 0x5d8 0x0000000000000004 (HASH) 0x62c 0x0000000000000019 (INIT_ARRAY) 0xb000 0x000000000000001b (INIT_ARRAYSZ) 16 (bytes) 0x000000006ffffff0 (VERSYM) 0x590 0x000000006ffffffe (VERNEED) 0x5a8 0x000000006fffffff (VERNEEDNUM) 1
> test-array.so: terminate called after throwing an instance of > 'std::runtime_error' > what(): Sections overlap > Makefile:17: recipe for target 'test-array.so' failed FWIW I got the same error in a PGO (and not-LTO) build.
Step back. Were you both using lld?
I was, yes.
I was as well. I have fixed the test in moz.build to correctly apply -fno-lto when one is using -flto=thin and that correctly applies for the .c file. However when linking the .o into a .so, -fno-lto is _not_ applied. Build: https://treeherder.mozilla.org/#/jobs?repo=try&revision=0484206c559e5a522737115b318b17f64132af56&selectedJob=178861247 (Ignore the failures on the non-lto build; they are unrelated. Command: [task 2018-05-16T23:20:10.640Z] 23:20:10 INFO - /builds/worker/workspace/build/src/sccache2/sccache /builds/worker/workspace/build/src/clang/bin/clang++ -B /builds/worker/workspace/build/src/gcc/bin -std=gnu++14 -Qunused-arguments -fuse-ld=lld -flto=thin -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -U_FORTIFY_SOURCE -Qunused-arguments -Wall -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wunreachable-code-return -Wwrite-strings -Wno-invalid-offsetof -Wclass-varargs -Wloop-analysis -Wc++1z-compat -Wcomma -Wimplicit-fallthrough -Werror=non-literal-null-conversion -Wstring-conversion -Wno-inline-new-delete -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wformat -Wformat-security -Wno-gnu-zero-variadic-macro-arguments -Wno-unknown-warning-option -Wno-return-type-c-linkage -D_GLIBCXX_USE_CXX11_ABI=0 -fno-sized-deallocation -fuse-ld=lld -flto=thin -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -U_FORTIFY_SOURCE -fno-strict-aliasing -fno-rtti -ffunction-sections -fdata-sections -fno-math-errno -pthread -pipe -fexceptions -g -O1 -fno-omit-frame-pointer -Werror -fPIC -shared -Wl,-h,test-array.so -o test-array.so -lpthread -flto=thin -Wl,-z,noexecstack -Wl,-z,text -Wl,-z,relro -Wl,--build-id -fuse-ld=lld -Wl,-rpath-link,/builds/worker/workspace/build/src/obj-firefox/dist/bin -Wl,-rpath-link,/usr/local/lib test-array.o -nostartfiles
That the linker invocation doesn't have -fno-lto doesn't matter. It can't lto non-ltoed .o files anyways. The core problem here is using lld. Do bfd ld or gold support thinlto? It would be better to use that on Linux, because lld is trying to be too smart for its own good, and the prevents elfhack from doing its job. See bug 1423822
(In reply to Mike Hommey [:glandium] from comment #31) > The core problem here is using lld. Do bfd ld or gold support thinlto? It > would be better to use that on Linux, because lld is trying to be too smart > for its own good, and the prevents elfhack from doing its job. See bug 1423822 I haven't looked at the details of bug 1423822, but as a general rule, we can and should fix/patch lld rather than avoid it. I'm sure they'd be open to a switch that disables or alters this behavior that you describe as "too smart for its own good". Just the other day I saw a checkin for a switch to fix some Chrome-specific perf regression.
Depends on: 1423822
Comment on attachment 8971637 [details] Bug 1457482 Add --enable-lto that turns on LTO https://reviewboard.mozilla.org/r/240396/#review254068 ::: build/unix/mozconfig.lto:20 (Diff revision 6) > if [ -e "$topsrcdir/gcc/bin/ld" ]; then > export CC="$CC -B $topsrcdir/gcc/bin" > export CXX="$CXX -B $topsrcdir/gcc/bin" > fi > > +ac_add_options --enable-lto To support -flto=thin vs full; and clang vs gcc; I'm pretty sure we need a configure flag that allows moz.build-based flag selection.
Blocks: 1465532
Attachment #8971705 - Attachment is obsolete: true
Blocks: 1465549
Comment on attachment 8971635 [details] Bug 1457482 Add lld to the clang-6-pre-linux64 toolchain for use in the LTO build https://reviewboard.mozilla.org/r/240392/#review254580 ::: commit-message-2243b:1 (Diff revision 6) > +Bug 1457482 Add a LTO Clang Toolchain r?glandium This doesn't add a toolchain anymore, please update the summary.
Attachment #8971635 - Flags: review?(mh+mozilla) → review+
Comment on attachment 8971636 [details] Bug 1457482 Add an LTO Build Target https://reviewboard.mozilla.org/r/240394/#review254582 ::: build/unix/elfhack/moz.build:17 (Diff revision 7) > - if '-flto' in CONFIG['OS_CFLAGS']: > + for f in CONFIG['OS_CFLAGS']: > + if f.startswith('-flto'): > - SOURCES['test-array.c'].flags += ['-fno-lto'] > + SOURCES['test-array.c'].flags += ['-fno-lto'] > - SOURCES['test-ctors.c'].flags += ['-fno-lto'] > + SOURCES['test-ctors.c'].flags += ['-fno-lto'] separate patch for this? ::: testing/mozharness/configs/builds/releng_sub_linux_configs/64_lto_tc.py:23 (Diff revision 7) > + 'TOOLTOOL_CACHE': '/builds/tooltool_cache', > + 'TOOLTOOL_HOME': '/builds', > + 'MOZ_CRASHREPORTER_NO_REPORT': '1', > + 'LC_ALL': 'C', > + }, > + 'mozconfig_variant': 'nightly-lto', I learned recently that you can actually pass mozharness config from the taskcluster config. So if you only really care about changing the mozconfig_variant here, you can do that in taskcluster config. Search for mozconfig_variant in taskcluster/ci/build/linux.yml for an example.
Attachment #8971636 - Flags: review?(mh+mozilla)
Comment on attachment 8971637 [details] Bug 1457482 Add --enable-lto that turns on LTO https://reviewboard.mozilla.org/r/240396/#review254584 ::: build/autoconf/sanitize.m4:20 (Diff revision 10) > + OS_CFLAGS="$OS_CFLAGS $MOZ_LTO_OS_CFLAGS" > + OS_CPPFLAGS="$OS_CPPFLAGS $MOZ_LTO_OS_CFLAGS" > + OS_CXXFLAGS="$OS_CXXFLAGS $MOZ_LTO_OS_CFLAGS" > + OS_LDFLAGS="$OS_LDFLAGS $MOZ_LTO_OS_LDFLAGS" What is it for? those variables are set from the non-prefixed one at the end of old-configure, so after this. ::: build/moz.configure/toolchain.configure:1295 (Diff revision 10) > -# Security Hardening > +# LTO > +# ============================================================== > + > +js_option('--enable-lto', > + nargs='?', > + default=False, default=False is the default. ::: build/moz.configure/toolchain.configure:1308 (Diff revision 10) > + osflags = [] > + osldflags = [] > + > + # clang and clang-cl LTO > + if 'clang' in c_compiler.type: > + # Until Bug 1457168 is fixed, I have to hardcode -fuse-ld=lld here I tend to frown upon `I` in code comments. ::: build/moz.configure/toolchain.configure:1314 (Diff revision 10) > + if len(value) and value[0].lower() == 'full': > + flags.append("-fuse-ld=lld") > + flags.append("-flto") > + ldflags.append("-flto") > + elif len(value) and value[0].lower() not in ['full', 'thin']: > + raise FatalCheckError('Only --enable-lto[=thin] and --enable-lto=full are supported.') A better way to do this is to add choices=('full', 'thin') to the option. ::: build/moz.configure/toolchain.configure:1322 (Diff revision 10) > + flags.append("-flto=thin") > + ldflags.append("-flto=thin") > + > + # gcc and other compilers > + elif value: > + flags.append("-flto=9") IIRC, the number after -flto= is the number of threads or processes to use. Hardcoding a number is not nice. There is -flto=jobserver, but that assumes the build backend passes the make jobserver file descriptors to the compiler. So I guess a kinda less bad thing would be to use the actual number of cores on the machine (multiprocessing.cpu_count(), see pgo_flags). BTW, -flto=n is only necessary on ldflags, not cflags.
Attachment #8971637 - Flags: review?(mh+mozilla)
Comment on attachment 8971636 [details] Bug 1457482 Add an LTO Build Target https://reviewboard.mozilla.org/r/240394/#review254742 ::: testing/mozharness/configs/builds/releng_sub_linux_configs/64_lto_tc.py:23 (Diff revision 7) > + 'TOOLTOOL_CACHE': '/builds/tooltool_cache', > + 'TOOLTOOL_HOME': '/builds', > + 'MOZ_CRASHREPORTER_NO_REPORT': '1', > + 'LC_ALL': 'C', > + }, > + 'mozconfig_variant': 'nightly-lto', I can minimize it further, but I do need to edit the default actions and stage platform so I think I still need the file.
Comment on attachment 8971637 [details] Bug 1457482 Add --enable-lto that turns on LTO https://reviewboard.mozilla.org/r/240396/#review254752 ::: build/autoconf/sanitize.m4:20 (Diff revision 10) > + OS_CFLAGS="$OS_CFLAGS $MOZ_LTO_OS_CFLAGS" > + OS_CPPFLAGS="$OS_CPPFLAGS $MOZ_LTO_OS_CFLAGS" > + OS_CXXFLAGS="$OS_CXXFLAGS $MOZ_LTO_OS_CFLAGS" > + OS_LDFLAGS="$OS_LDFLAGS $MOZ_LTO_OS_LDFLAGS" I had thought this was needed from when I got gcc's -flto working, but perhaps they are not needed afterall (because, as you said, they are already set)
Comment on attachment 8971636 [details] Bug 1457482 Add an LTO Build Target https://reviewboard.mozilla.org/r/240394/#review255260 ::: testing/mozharness/configs/builds/releng_sub_linux_configs/64_lto_tc.py:9 (Diff revision 8) > + 'build', > + 'check-test', > + # 'update', > + ], > + 'stage_platform': 'linux64-lto', > + 'mozconfig_variant': 'nightly-lto', Note you can set non mozconfig_variant values too in taskcluster config.
Attachment #8971636 - Flags: review?(mh+mozilla) → review+
Comment on attachment 8982571 [details] Bug 1457482 Correct elfhack's LTO detection to handle -flto=thin https://reviewboard.mozilla.org/r/248552/#review255262
Attachment #8982571 - Flags: review?(mh+mozilla) → review+
Comment on attachment 8971637 [details] Bug 1457482 Add --enable-lto that turns on LTO https://reviewboard.mozilla.org/r/240396/#review255264 ::: build/moz.configure/toolchain.configure:1309 (Diff revision 11) > + flags.append("-fuse-ld=lld") > + flags.append("-flto") > + ldflags.append("-flto") does clang-cl accept those without -Xclang?
Attachment #8971637 - Flags: review?(mh+mozilla) → review+
clang-cl accepts -flto[=thin] but we probably shouldn't pass it -fuse-ld
Keywords: checkin-needed
Pushed by nerli@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/bfc39006be1b Add lld to the clang-6-pre-linux64 toolchain for use in the LTO build r=glandium https://hg.mozilla.org/integration/autoland/rev/36132fa62b44 Correct elfhack's LTO detection to handle -flto=thin r=glandium https://hg.mozilla.org/integration/autoland/rev/8b89c933a703 Add an LTO Build Target r=glandium https://hg.mozilla.org/integration/autoland/rev/bb7dec4331c1 Add --enable-lto that turns on LTO r=glandium
Keywords: checkin-needed
Blocks: 1469088
Blocks: 1490675
Version: Version 3 → 3 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: