Use LLVM LTO instead of IR types to improve compatibility

Use LLVM LTO instead of IR types to improve compatibility

LLVM IR types use ".ll" and ".bc" suffixes which can break compatiblity
with the existing software, so we switch to the LLVM LTO types instead
which use the standard ".s" and ".o" suffixes.

BUG=https://bugs.chromium.org/p/nativeclient/issues/detail?id=4347
R=dschuff@chromium.org

Committed: d57a6f8b109145f0732906ff94c0380c0ee41953

[Petr Hosek, 2016-03-17 22:04:27]

Description was changed from

==========
Use LLVM LTO instead of IR types to improve compatibility

LLVM IR types use ".ll" and ".bc" suffixes which can break compatiblity
with the existing code, so we switch to the LLVM LTO types instead which
use the standard ".s" and ".o" suffixes.

BUG=
==========

to

==========
Use LLVM LTO instead of IR types to improve compatibility

LLVM IR types use ".ll" and ".bc" suffixes which can break compatiblity
with the existing code, so we switch to the LLVM LTO types instead which
use the standard ".s" and ".o" suffixes.

BUG=https://bugs.chromium.org/p/nativeclient/issues/detail?id=4347
R=dschuff@chromium.org
==========

[Petr Hosek, 2016-03-17 22:04:27]

phosek@chromium.org changed reviewers:
+ dschuff@chromium.org

[Derek Schuff, 2016-03-18 00:19:12]

On 2016/03/17 22:04:40, Petr Hosek wrote:

This looks fine but what do you mean by "break compatibility with existing
code"? what code, in what way?

[Derek Schuff, 2016-03-18 00:20:24]

On 2016/03/18 00:19:12, Derek Schuff wrote:
> On 2016/03/17 22:04:40, Petr Hosek wrote:
> 
> This looks fine but what do you mean by "break compatibility with existing
> code"? what code, in what way?

oh and is the extension of the files the only thing that changes, or what else
does this change cause? Just trying to understand.

[Petr Hosek, 2016-03-18 00:28:41]

On 2016/03/18 00:20:24, Derek Schuff wrote:
> On 2016/03/18 00:19:12, Derek Schuff wrote:
> > On 2016/03/17 22:04:40, Petr Hosek wrote:
> > 
> > This looks fine but what do you mean by "break compatibility with existing
> > code"? what code, in what way?
> 
> oh and is the extension of the files the only thing that changes, or what else
> does this change cause? Just trying to understand.

This came out when testing the new driver in webports, there are quite a few
packages out there which test the default extension during configure step
(executing something akin to `clang -c conftest.c`), which would be .bc before
this change, but build rules in their makefiles assume that .o (they often use
something akin to `%.o : %.c`). The existing Python driver already handles that
by forcing the default extension to be .o. Arguably, this is about correctness
vs compatibility, ideally we would use the .bc extension because our output
files are bitcode, but until we fix all the software out there we should
probably err on the side of compatibility.

[Petr Hosek, 2016-03-18 00:29:28]

Description was changed from

==========
Use LLVM LTO instead of IR types to improve compatibility

LLVM IR types use ".ll" and ".bc" suffixes which can break compatiblity
with the existing code, so we switch to the LLVM LTO types instead which
use the standard ".s" and ".o" suffixes.

BUG=https://bugs.chromium.org/p/nativeclient/issues/detail?id=4347
R=dschuff@chromium.org
==========

to

==========
Use LLVM LTO instead of IR types to improve compatibility

LLVM IR types use ".ll" and ".bc" suffixes which can break compatiblity
with the existing software, so we switch to the LLVM LTO types instead
which use the standard ".s" and ".o" suffixes.

BUG=https://bugs.chromium.org/p/nativeclient/issues/detail?id=4347
R=dschuff@chromium.org
==========

[Derek Schuff, 2016-03-18 00:40:35]

On 2016/03/18 00:28:41, Petr Hosek wrote:
> On 2016/03/18 00:20:24, Derek Schuff wrote:
> > On 2016/03/18 00:19:12, Derek Schuff wrote:
> > > On 2016/03/17 22:04:40, Petr Hosek wrote:
> > > 
> > > This looks fine but what do you mean by "break compatibility with existing
> > > code"? what code, in what way?
> > 
> > oh and is the extension of the files the only thing that changes, or what
else
> > does this change cause? Just trying to understand.
> 
> This came out when testing the new driver in webports, there are quite a few
> packages out there which test the default extension during configure step
> (executing something akin to `clang -c conftest.c`), which would be .bc before
> this change, but build rules in their makefiles assume that .o (they often use
> something akin to `%.o : %.c`). The existing Python driver already handles
that
> by forcing the default extension to be .o. Arguably, this is about correctness
> vs compatibility, ideally we would use the .bc extension because our output
> files are bitcode, but until we fix all the software out there we should
> probably err on the side of compatibility.

Makes sense. Probably we should use .o anywya because from the perspective of
the user it serves the same purpose as an object file. That the object file has
LLVM bitcode is irrelevant to them.

LGTM

[Petr Hosek, 2016-03-18 18:50:17]

Description was changed from

==========
Use LLVM LTO instead of IR types to improve compatibility

LLVM IR types use ".ll" and ".bc" suffixes which can break compatiblity
with the existing software, so we switch to the LLVM LTO types instead
which use the standard ".s" and ".o" suffixes.

BUG=https://bugs.chromium.org/p/nativeclient/issues/detail?id=4347
R=dschuff@chromium.org
==========

to

==========
Use LLVM LTO instead of IR types to improve compatibility

LLVM IR types use ".ll" and ".bc" suffixes which can break compatiblity
with the existing software, so we switch to the LLVM LTO types instead
which use the standard ".s" and ".o" suffixes.

BUG=https://bugs.chromium.org/p/nativeclient/issues/detail?id=4347
R=dschuff@chromium.org

Committed: d57a6f8b109145f0732906ff94c0380c0ee41953
==========

[Petr Hosek, 2016-03-18 18:50:19]

Committed patchset #1 (id:1) manually as
d57a6f8b109145f0732906ff94c0380c0ee41953 (presubmit successful).