llvm-svn: 179021

llvm-svn: 179020

nested quoting schemes, and they're not important here...

llvm-svn: 179014

llvm-svn: 179010

llvm-svn: 179009

llvm-svn: 179006

I've managed to convince myself that AArch64's acquire/release
instructions are sufficient to guarantee C++11's required semantics,
even in the sequentially-consistent case.

llvm-svn: 179005

I couldn't touch this file and not clean it up some. These reformattings
brought to you by clang-format, with some minor adjustments by me. More
spring cleaning to follow here.

llvm-svn: 179004

internal linkage and so wasn't a patent bug, it doesn't make any sense
here. We can avoid even calling operator<< by just embedding the newline
in the string literals that were already being streamed out. It also
gives the impression of some line-ending agnosticisms which is not
present, and that flushing happens when it doesn't.

If we want to use std::endl, we could do that, but honestly it doesn't
seem remotely worth it. Using '\n' directly is much more clear when
working with raw_ostream.

It also happens to fix builds with old crufty GCC STL implementations
that include std::endl into the global namespace (or headers written to
be compatible with such atrocities).

llvm-svn: 179003

llvm-svn: 179001

First, we should not cheat: fsel-based lowering of select_cc is a
finite-math-only optimization (the ISA manual, section F.3 of v2.06, makes
this clear, as does a note in our own README).

This also adds fsel-based lowering of EQ and NE condition codes. As it turned
out, fsel generation was covered by a grand total of zero regression test
cases. I've added some test cases to cover the existing behavior (which is now
finite-math only), as well as the new EQ cases.

llvm-svn: 179000

The code in getTypeConversion attempts to promote the element vector type
before it trys to split or widen the vector.
After it failed finding a legal vector type by promoting it would continue using
the promoted vector element type. Thereby missing legal splitted vector types.
For example the type v32i32 that has a legal split of 4 x v3i32 on x86/sse2
would be transformed to: v32i256 and from there on successively split to:
v16i256, v8i256, v1i256 and then finally ends up as an i64 type.
By resetting the vector element type to the original vector element type that
existed before the promotion the code will attempt to split the vector type to
smaller vector widths of the same type.

llvm-svn: 178999

llvm-svn: 178998

llvm-svn: 178997

llvm-svn: 178996

llvm-svn: 178995

llvm-svn: 178994

There is still no support for byval arguments (which I don't think are
needed) and varargs.

llvm-svn: 178993

These were the last missing forwarding functions. Also consistently use
the forwarding functions instead of using MachOObj directly.

llvm-svn: 178992

LoadCommandInfo was needed to keep a command and its offset in the file. Now
that we always have a pointer to the command, we don't need the offset.

llvm-svn: 178991

This avoids using MachOObject::getLoadCommandInfo.

llvm-svn: 178990

llvm-svn: 178989

llvm-svn: 178988

llvm-svn: 178987

llvm-svn: 178986

llvm-svn: 178985

llvm-svn: 178984

llvm-svn: 178983

llvm-svn: 178982

llvm-svn: 178981

llvm-svn: 178980

llvm-svn: 178979

llvm-svn: 178978

llvm-svn: 178977

llvm-svn: 178976

The fix for PR14972 in r177055 introduced a real think-o in the *store*
side, likely because I was much more focused on the load side. While we
can arbitrarily widen (or narrow) a loaded value, we can't arbitrarily
widen a value to be stored, as that changes the width of memory access!
Lock down the code path in the store rewriting which would do this to
only handle the intended circumstance.

All of the existing tests continue to pass, and I've added a test from
the PR.

llvm-svn: 178974

A few were missed in r178972.

llvm-svn: 178973

llvm-svn: 178972

llvm-svn: 178971

llvm-svn: 178970