Disable LTO for AVX2 code.

Disable LTO for AVX2 code.

LLVM currently lacks the ability to compile different parts of an LTO'd
object for different subtargets. Disable it here to avoid needing to
compile the rest of the application with AVX2 when using LTO.

BUG=chromium:453195
R=thakis@chromium.org

Committed: https://chromium.googlesource.com/chromium/deps/libvpx/+/7464c834e05060af9cf8eb29032a8ad30828eec6

[Nico, 2015-02-04 19:06:03]

https://codereview.chromium.org/891933003/diff/1/libvpx_srcs_x86_64_intrinsic...
File libvpx_srcs_x86_64_intrinsics.gypi (right):

https://codereview.chromium.org/891933003/diff/1/libvpx_srcs_x86_64_intrinsic...
libvpx_srcs_x86_64_intrinsics.gypi:1: # This file is generated. Do not edit.
These files are generated by a shell script.

There are other places that enable avx. This seems like a fairly brittle thing –
maybe enabling avx globally is easier to get things going? (If we want to use
this for real, we'll need multi-arch support in llvm, and until then turning on
avx globally seems simpler to me. not sure, though.)

[Johann, 2015-02-04 19:10:50]

johannkoenig@google.com changed reviewers:
+ johannkoenig@google.com

[Johann, 2015-02-04 19:10:50]

Please see generate_gypi.sh around line 108. LTO is disabled for neon targets
(for a similar reason?)

Also may need to rebase. I had an aborted roll in this repo that just got rolled
back: https://codereview.chromium.org/897063002

[pcc, 2015-02-04 19:16:03]

On 2015/02/04 19:06:03, Nico wrote:
>
https://codereview.chromium.org/891933003/diff/1/libvpx_srcs_x86_64_intrinsic...
> File libvpx_srcs_x86_64_intrinsics.gypi (right):
> 
>
https://codereview.chromium.org/891933003/diff/1/libvpx_srcs_x86_64_intrinsic...
> libvpx_srcs_x86_64_intrinsics.gypi:1: # This file is generated. Do not edit.
> These files are generated by a shell script.
> 
> There are other places that enable avx. This seems like a fairly brittle thing
–
> maybe enabling avx globally is easier to get things going? (If we want to use
> this for real, we'll need multi-arch support in llvm, and until then turning
on
> avx globally seems simpler to me. not sure, though.)

I enabled AVX1 globally in https://codereview.chromium.org/884923002 . This is
the first dependency on AVX2 that I am aware of. At this point it's probably
easier to disable it here, mainly because support for AVX2 isn't as widespread
(for example, my workstation doesn't have it).

[Johann, 2015-02-04 19:19:51]

On 2015/02/04 19:16:03, pcc wrote:
> I enabled AVX1 globally

If AVX1 is required that has some good implications for libvpx since in some
cases we may have sse2, ssse3, and sse4.1 versions of the same code. If we can
guarantee sse4.1 then we can remove the lower opt levels.

But I may be seriously misreading that.

[pcc, 2015-02-04 19:24:25]

On 2015/02/04 19:19:51, Johann wrote:
> On 2015/02/04 19:16:03, pcc wrote:
> > I enabled AVX1 globally
> 
> If AVX1 is required that has some good implications for libvpx since in some
> cases we may have sse2, ssse3, and sse4.1 versions of the same code. If we can
> guarantee sse4.1 then we can remove the lower opt levels.
> 
> But I may be seriously misreading that.

In https://codereview.chromium.org/884923002 I enabled AVX1 globally for the
(experimental) LTO build only, as a temporary measure to work around limitations
in LLVM's LTO. Once those limitations disappear the intention is to fall back to
the baseline processor family in LTO (i.e. the targeted processor family is not
changing as far as I know).

[Nico, 2015-02-04 19:31:34]

Johann: AVX1 isn't required; this is for an experimental test-only config.

pcc: This might be the only AVX2 at the moment, but I thought I saw the skia
folks playing with this too (or was that AVX1 too?), and other places will use
it eventually. It seems like a maintenance issue if every client will need a "if
lto then no avx2" thingy :-/

In any case, as said above, this is a generated file, you need to edit the
script that generates it too.

[pcc, 2015-02-04 19:51:45]

On 2015/02/04 19:31:34, Nico wrote:
> Johann: AVX1 isn't required; this is for an experimental test-only config.
> 
> pcc: This might be the only AVX2 at the moment, but I thought I saw the skia
> folks playing with this too (or was that AVX1 too?), and other places will use
> it eventually. It seems like a maintenance issue if every client will need a
"if
> lto then no avx2" thingy :-/

We might want to introduce a .gypi file with the logic for enabling avx2 if this
becomes a problem. Of course we'd hope to try to fix LLVM before we need to do
this.

> In any case, as said above, this is a generated file, you need to edit the
> script that generates it too.

Done. (I couldn't get the script to run properly so I applied its changes
manually.)

[Nico, 2015-02-04 20:04:56]

lgtm, but please add some bug reference to the TODO

[pcc, 2015-02-04 20:23:28]

New patchsets have been uploaded after l-g-t-m from thakis@chromium.org

[pcc, 2015-02-04 20:23:40]

The CQ bit was checked by pcc@google.com

[commit-bot: I haz the power, 2015-02-04 20:28:11]

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

[commit-bot: I haz the power, 2015-02-04 20:28:12]

Commit queue rejected this change because it did not recognize the base URL.
Please commit your change manually.

[Johann, 2015-02-04 22:07:35]

On 2015/02/04 20:28:12, I haz the power (commit-bot) wrote:
> Commit queue rejected this change because it did not recognize the base URL.
> Please commit your change manually.

This repository does not use the commit queue. You must land with 'git cl land'
and then update the src/DEPS entry for libvpx.

[Nico, 2015-02-05 20:45:57]

Committed patchset #4 (id:60001) manually as
7464c834e05060af9cf8eb29032a8ad30828eec6 (presubmit successful).

[Nico, 2015-02-05 20:46:43]

I landed this here:
https://chromium.googlesource.com/chromium/deps/libvpx/+/7464c834e05060af9cf8...

Sorry, I messed up the attribution. (Hadn't committed to libvpx since it moved
to git.)