Stop building the gold plugin and linking lld against tcmalloc.

Stop building the gold plugin and linking lld against tcmalloc.

As far as I am aware, there are no remaining users of the gold plugin
(v8, the last user I am aware of, stopped downloading it as part of its
build in https://chromium-review.googlesource.com/547058 and removed
build support in https://chromium-review.googlesource.com/549300),
so we no longer need to build it.

Also, now that we have started using ThinLTO in official builds,
not only is the perf gain of linking lld against tcmalloc not as
important, but I have also measured it to be smaller in relative
terms. For base_unittests:

With tcmalloc (median of 6): 42.29s
With glibc malloc: 44.61s

So about 5%, which is about half of what I measured for regular LTO.
And of course the absolute delta is smaller as well. I think that
justifies removing it. We can re-evaluate for the toolchain as a
whole at a later time.

BUG=607968
R=thakis@chromium.org,hans@chromium.org

Review-Url: https://codereview.chromium.org/2963693002
Cr-Commit-Position: refs/heads/master@{#483149}
Committed: https://chromium.googlesource.com/chromium/src/+/6489fe94c6edc435f5f0b291032c0e8883212afd

[Nico, 2017-06-28 15:07:00]

Nice! lgtm

https://codereview.chromium.org/2963693002/diff/1/tools/clang/scripts/update.py
File tools/clang/scripts/update.py (right):

https://codereview.chromium.org/2963693002/diff/1/tools/clang/scripts/update....
tools/clang/scripts/update.py:37: CLANG_SUB_REVISION=2
Be sure to push the new binaries to goma before landing this. (Try jobs will
enforce this.)

https://codereview.chromium.org/2963693002/diff/1/tools/clang/scripts/update....
tools/clang/scripts/update.py:547: '-DCMAKE_RANLIB=' + ranlib,
Why is this needed now when it wasn't previously?

From what I understand, you're retiring lto_cflags and lto_ldflags in favor of
using the cmake support (LLVM_ENABLE_LTO=thin, LLVM_USE_LINKER=lld), and then
you pass the "normal" cflags and cxxflags which means you don't need to repeat
the --gcc-toolchain flag, but why do we now have to pass in ar and ranlib when
we didn't have to previously?

[pcc1, 2017-06-28 17:46:46]

https://codereview.chromium.org/2963693002/diff/1/tools/clang/scripts/update.py
File tools/clang/scripts/update.py (right):

https://codereview.chromium.org/2963693002/diff/1/tools/clang/scripts/update....
tools/clang/scripts/update.py:547: '-DCMAKE_RANLIB=' + ranlib,
On 2017/06/28 15:06:59, Nico (vacation Jun 30-Jul 11) wrote:
> Why is this needed now when it wasn't previously?
>
> From what I understand, you're retiring lto_cflags and lto_ldflags in favor of
> using the cmake support (LLVM_ENABLE_LTO=thin, LLVM_USE_LINKER=lld), and then
> you pass the "normal" cflags and cxxflags which means you don't need to repeat
> the --gcc-toolchain flag, but why do we now have to pass in ar and ranlib when
> we didn't have to previously?

The archiver needs to create symbol tables for archive members that are bitcode
files because the linker expects them to be there. Previously we were doing that
by using GNU ar and ranlib and teaching them to read symbol tables from bitcode
files with the gold plugin (using the symlink created on line 552). Since we are
no longer building the plugin, we need an ar and ranlib that understand bitcode
files natively, which is what llvm-ar and llvm-ranlib are.

I'll add a comment about that.

[pcc1, 2017-06-28 18:21:17]

The CQ bit was checked by pcc@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-06-28 18:21:48]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-06-28 21:25:22]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-06-28 21:25:23]

Dry run: This issue passed the CQ dry run.

[pcc1, 2017-06-28 21:26:26]

The CQ bit was checked by pcc@chromium.org

[pcc1, 2017-06-28 21:26:26]

The patchset sent to the CQ was uploaded after l-g-t-m from thakis@chromium.org
Link to the patchset: https://codereview.chromium.org/2963693002/#ps20001
(title: "Add comment")

[commit-bot: I haz the power, 2017-06-28 21:27:12]

CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-06-28 21:30:46]

CQ is committing da patch.

Bot data: {"patchset_id": 20001, "attempt_start_ts": 1498685186348660,
"parent_rev": "06129aec96668a5747023b173b8beab1e0651036", "commit_rev":
"6489fe94c6edc435f5f0b291032c0e8883212afd"}

[commit-bot: I haz the power, 2017-06-28 21:31:02]

Description was changed from

==========
Stop building the gold plugin and linking lld against tcmalloc.

As far as I am aware, there are no remaining users of the gold plugin
(v8, the last user I am aware of, stopped downloading it as part of its
build in https://chromium-review.googlesource.com/547058 and removed
build support in https://chromium-review.googlesource.com/549300),
so we no longer need to build it.

Also, now that we have started using ThinLTO in official builds,
not only is the perf gain of linking lld against tcmalloc not as
important, but I have also measured it to be smaller in relative
terms. For base_unittests:

With tcmalloc (median of 6): 42.29s
With glibc malloc: 44.61s

So about 5%, which is about half of what I measured for regular LTO.
And of course the absolute delta is smaller as well. I think that
justifies removing it. We can re-evaluate for the toolchain as a
whole at a later time.

BUG=607968
R=thakis@chromium.org,hans@chromium.org
==========

to

==========
Stop building the gold plugin and linking lld against tcmalloc.

As far as I am aware, there are no remaining users of the gold plugin
(v8, the last user I am aware of, stopped downloading it as part of its
build in https://chromium-review.googlesource.com/547058 and removed
build support in https://chromium-review.googlesource.com/549300),
so we no longer need to build it.

Also, now that we have started using ThinLTO in official builds,
not only is the perf gain of linking lld against tcmalloc not as
important, but I have also measured it to be smaller in relative
terms. For base_unittests:

With tcmalloc (median of 6): 42.29s
With glibc malloc: 44.61s

So about 5%, which is about half of what I measured for regular LTO.
And of course the absolute delta is smaller as well. I think that
justifies removing it. We can re-evaluate for the toolchain as a
whole at a later time.

BUG=607968
R=thakis@chromium.org,hans@chromium.org

Review-Url: https://codereview.chromium.org/2963693002
Cr-Commit-Position: refs/heads/master@{#483149}
Committed:
https://chromium.googlesource.com/chromium/src/+/6489fe94c6edc435f5f0b291032c...
==========

[commit-bot: I haz the power, 2017-06-28 21:31:04]

Committed patchset #2 (id:20001) as
https://chromium.googlesource.com/chromium/src/+/6489fe94c6edc435f5f0b291032c...