llvm-svn: 166080

llvm-svn: 166079

llvm-svn: 166078

llvm-svn: 166077

llvm-svn: 166076

llvm-svn: 166075

llvm-svn: 166074

llvm-svn: 166073

target options around so they can be accessed at any point (rather
than keeping them transient).

llvm-svn: 166072

explicitly specified iff it was specified in the declaration.

llvm-svn: 166071

llvm-svn: 166070

This is consistent/interoperable with GCC 4.7 (& __cxa_deleted_function isn't
present in 4.4 - not sure when it got added, but you'll need something with
that function available for this to work).

llvm-svn: 166069

PR14098 contains an example where we would rematerialize a MOV8ri
immediately after the original instruction:

  %vreg7:sub_8bit<def> = MOV8ri 9; GR32_ABCD:%vreg7
  %vreg22:sub_8bit<def> = MOV8ri 9; GR32_ABCD:%vreg7

Besides being pointless, it is also wrong since the original instruction
only redefines part of the register, and the value read by the new
instruction is wrong.

The problem was the LiveRangeEdit::allUsesAvailableAt() didn't
special-case OrigIdx == UseIdx and found the wrong SSA value.

llvm-svn: 166068

A fix for PR14098, including the test case is in the next commit.

llvm-svn: 166067

rdar://12439123

llvm-svn: 166066

Because PNaCl bitcode must be target-independent, it uses some
different bitcode representations from other targets (e.g. byval and
sret for structures). This means that without additional type
information, it cannot meet some native ABI requirements for some
targets (e.g. passing structures containing unions by value on
x86-64). To allow generation of code which uses the correct native
ABIs, we also support triples such as x86_64-nacl, which uses
target-dependent IR (as opposed to le32-nacl, which uses byval and
sret).

To allow interoperation between the two types of code, this patch adds
a calling convention attribute to be used in code compiled with the
target-dependent triple, which will generate code using the le32-style
bitcode. This calling convention does not need to be explicitly
supported in the backend because it determines bitcode representation
rather than native conventions (the backend just needs to undersand
how to handle byval and sret for the Native Client OS).

This patch implements __attribute__((pnaclcall)) to generate calls in
bitcode according to the le32 bitcode conventions, an attribute which
is accepted by any Native Client target, but issues a warning
otherwise.

llvm-svn: 166065

llvm-svn: 166064

front-end and the AsmParser.  No functional change intended.

llvm-svn: 166063

the SB API's that evaluate expressions.

<rdar://problem/12457211>

llvm-svn: 166062

An obfuscated splat is where the frontend poorly generates code for a splat
using several different shuffles to create the splat, i.e.,

  %A = load <4 x float>* %in_ptr, align 16
  %B = shufflevector <4 x float> %A, <4 x float> undef, <4 x i32> <i32 0, i32 0, i32 undef, i32 undef>
  %C = shufflevector <4 x float> %B, <4 x float> %A, <4 x i32> <i32 0, i32 1, i32 4, i32 undef>
  %D = shufflevector <4 x float> %C, <4 x float> %A, <4 x i32> <i32 0, i32 1, i32 2, i32 4>

llvm-svn: 166061

llvm-svn: 166060

(original functionality committed in r99807, refactored in r160373)

llvm-svn: 166059

<rdar://problem/12446320> Fixing an issue with our Driver where setting an immediate output would not cause suppression of the final printout. This allows effective output redirection for Python commands

llvm-svn: 166058

to work properly; when doing bare-boards rom debugging
force the OS to be one of those when initializing llvm.
<rdar://problem/12504138>

llvm-svn: 166057

llvm-svn: 166056

This patch fixes an issue where if lldb fails to attach to a process (ie. invalid pid) on Linux, the process monitor thread gets stuck waiting for a signal from the attach thread, which never comes due to not being signaled. It also implements StopOpThread which is used for both attach/launch cases as I'm not aware of any special handling needed for the attach case. Also, propagate 'Error' from the Detach function instead of using a bool.

llvm-svn: 166055

llvm-svn: 166054

llvm-svn: 166053

We generalize r166040 to handle ABI alignment issues for all types.

rdar://12439123

llvm-svn: 166052

llvm-svn: 166051

llvm-svn: 166050

llvm-svn: 166049

llvm-svn: 166048

@implementation.

llvm-svn: 166047

llvm+clang+compiler-rt bootstrap.

llvm-svn: 166046

llvm-svn: 166045

We expand varargs in clang and the call site is handled in the back end, it is
hard to match exactly how illegal vectors are handled in the backend. Therefore,
we legalize the illegal vector types in clang:
if (Size <= 32), legalize to i32.
if (Size == 64), legalize to v2i32.
if (Size == 128), legalize to v4i32.
if (Size > 128), use indirect.

rdar://12439123

llvm-svn: 166043

We create an aligned temporary space and copy the content over from ap.cur to
the temporary space. This is necessary if the natural alignment of the type is
greater than the ABI alignment.

rdar://12439123

llvm-svn: 166040

This implementation doesn't warn on anything that GCC doesn't warn on with the
exception of templates specializations (GCC doesn't warn, Clang does). The
specific skipped cases (boolean, constant expressions, enums) are open for
debate/adjustment if anyone wants to demonstrate that GCC is being overly
conservative here. The only really obvious false positive I found was in the
Clang regression suite's MPI test - apparently MPI uses specific flag values in
pointer constants. (eg: #define FOO (void*)~0)

llvm-svn: 166039

command line to dotest.py, replace / with _ in
the logfile names that mention that compiler so
that we don't try to put log files in weird
places.

llvm-svn: 166038