Almost all instructions that takes a 128 bits reg as input (fetch, export...)
have the abilities to swizzle their argument and output. Instead of printing
default swizzle for each 128 bits reg, rename T*.XYZW to T* and let instructions
print potentially optimized swizzles themselves.

llvm-svn: 182124

llvm-svn: 182123

llvm-svn: 182122

llvm-svn: 182121

is used for Objective-C++’s dictionary subscripting. This is done by filtering
out all placeholder types before check on lowering of the
common expression is done. // rdar://1374918.
Reviewed by John McCall.

llvm-svn: 182120

UseAutoActions.cpp:48:17: error: redefinition of 'E' with a different type.

llvm-svn: 182119

Introduce a new object library, RTSanitizerCommonLibc, which will contain
the subset of sanitizer_common with libc dependencies. RTSanitizerCommon
contains the remainder of sanitizer_common, and is intended to have no
libc dependencies. Begin moving code to RTSanitizerCommonLibc, starting
with sanitizer_common.cc, whose libc-dependent portion is moved to
sanitizer_common_libcdep.cc, the first member of the new library.

This split affects the CMake build only.  The makefile build continues
to produce the full sanitizer_common library.

llvm-svn: 182118

llvm-svn: 182117

Modifies the log directory to ensure that the log file will be found on tear-down (i.e. for CI agents that clean up artifacts aggressively).

- Uses the cwd following the model of TestPublicAPIHeaders.py

llvm-svn: 182116

- On Linux, the partial back-trace after an assert can cause the basic test to fail as discussed on lldb-dev.
- Uses SBFrame to walk up the stack to the assert site and tests expression evaluation of locals, globals and arguments.

Thanks to Daniel for review and testing on OS/X.

llvm-svn: 182115

variables.

UseAuto used to match initialized variable declarations independently of
whether they were defined in a declaration list or as a single declaration.
Now it matches declaration statements where every variable declaration is
initialized.

llvm-svn: 182114

Reviewed-by: Vincent Lejeune <vljn@ovi.com>

https://bugs.freedesktop.org/show_bug.cgi?id=64193
https://bugs.freedesktop.org/show_bug.cgi?id=64257
https://bugs.freedesktop.org/show_bug.cgi?id=64320

NOTE: This is a candidate for the 3.3 branch.
llvm-svn: 182113

llvm-svn: 182112

- Also removes a redundant import statement.

llvm-svn: 182111

llvm-svn: 182110

 This is to generate correct framesetup code when the function
 has variable sized allocas.

llvm-svn: 182108

[ASan] Make the regression test for time(NULL) Linux-specific, as it crashes on Darwin (and the problem used to occur on Linux).
Do not use zero-based shadow for the time() test.

llvm-svn: 182107

llvm-svn: 182104

Shuffles that only move an element into position 0 of the vector are common in
the output of the loop vectorizer and often generate suboptimal code when SSSE3
is not available. Lower them to vector shifts if possible.

We still prefer palignr over psrldq because it has higher throughput on
sandybridge.

llvm-svn: 182102

llvm-svn: 182101

llvm-svn: 182100

- Also added a comment as lldb doesn't flush the instruction cache after dy-load.

llvm-svn: 182099

which doesn't resolve the deeper problem.

llvm-svn: 182098

[PowerPC] Fix hi/lo encoding in old-style code emitter

This patch implements the equivalent change to r182091/r182092
in the old-style code emitter.  Instead of having two separate
16-bit immediate encoding routines depending on the instruction,
this patch introduces a single encoder that checks the machine
operand flags to decide whether the low or high half of a
symbol address is required.

Since now both encoders make no further distinction between
"symbolLo" and "symbolHi", the .td operand can now use a
single getS16ImmEncoding method.

Tested by running the old-style JIT tests on 32-bit Linux.

llvm-svn: 182097

This shares the warn_attribute_unused diagnostic and reduces the
indentation level.  No functionality change.

llvm-svn: 182096

llvm-svn: 182094

llvm-svn: 182093

[PowerPC] Merge/rename PPC fixup types

Now that fixup_ppc_ha16 and fixup_ppc_lo16 are being treated exactly
the same everywhere, it no longer makes sense to have two fixup types.

This patch merges them both into a single type fixup_ppc_half16,
and renames fixup_ppc_lo16_ds to fixup_ppc_half16ds for consistency.
(The half16 and half16ds names are taken from the description of
relocation types in the PowerPC ABI.)

No change in code generation expected.

llvm-svn: 182092

[PowerPC] Fix processing of ha16/lo16 fixups

The current PowerPC MC back end distinguishes between fixup_ppc_ha16
and fixup_ppc_lo16, which are determined by the instruction the fixup
applies to, and uses this distinction to decide whether a fixup ought
to resolve to the high or the low part of a symbol address.

This isn't quite correct, however.  It is valid -if unusual- assembler
to use, e.g.
  li 1, symbol@ha
or
  lis 1, symbol@l
Whether the high or the low part of the address is used depends solely
on the @ suffix, not on the instruction.

In addition, both
  li 1, symbol
and
  lis 1, symbol
are valid, assuming the symbol address fits into 16 bits; again, both
will then refer to the actual symbol value (so li will load the value
itself, while lis will load the value shifted by 16).


To fix this, two places need to be adapted.  If the fixup cannot be
resolved at assembler time, a relocation needs to be emitted via
PPCELFObjectWriter::getRelocType.  This routine already looks at
the VK_ type to determine the relocation.  The only problem is that
will reject any _LO modifier in a ha16 fixup and vice versa.  This
is simply incorrect; any of those modifiers ought to be accepted
for either fixup type.

If the fixup *can* be resolved at assembler time, adjustFixupValue
currently selects the high bits of the symbol value if the fixup
type is ha16.  Again, this is incorrect; see the above example
  lis 1, symbol

Now, in theory we'd have to respect a VK_ modifier here.  However,
in fact common code never even attempts to resolve symbol references
using any nontrivial VK_ modifier at assembler time; it will always
fall back to emitting a reloc and letting the linker handle it.

If this ever changes, presumably there'd have to be a target callback
to resolve VK_ modifiers.  We'd then have to handle @ha etc. there.

llvm-svn: 182091

llvm-svn: 182090

it was added to debug mysterious hangs, but it does not seem to happen anymore
now it only clutter up output

llvm-svn: 182089

this is required to handle Object.Wait()

llvm-svn: 182088

llvm-svn: 182087

llvm-svn: 182086

the JIT object (including XFAIL an ARM test that now needs fixing). Also renames
internal function for consistency.

llvm-svn: 182085

This is a candidate for the stable branch.

Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=64694



Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
llvm-svn: 182084

This optimizes some spurious edges resulting from PseudoObjectExprs.
This required far more changes than I anticipated.  The current
ParentMap does not record any hierarchy information between
a PseudoObjectExpr and its *semantic* expressions that may be
wrapped in OpaqueValueExprs, which are the expressions actually
laid out in the CFG.  This means the arrow pruning logic could
not map from an expression to its containing PseudoObjectExprs.

To solve this, this patch adds a variant of ParentMap that
returns the "semantic" parentage of expressions (essentially
as they are viewed by the CFG).  This alternate ParentMap is then
used by the arrow reducing logic to identify edges into pseudo
object expressions, and then eliminate them.

llvm-svn: 182083

Basically, the new rule is: The opening "{" always has to be on the
same line as the first element if the braced list is nested
(e.g. in another braced list or in a function).

The solution that clang-format produces almost always adheres to this
rule anyway and this makes clang-format significantly faster for larger
lists. Added a test cases for the only exception I could find
(which doesn't seem to be very important at first sight).

llvm-svn: 182082

As asked for by Sean, putting the video into the docs.

llvm-svn: 182081

[ASan] Fix allow_user_segv.cc on Darwin (32-bit build required a SIGBUS handler instead of the SIGSEGV one)

llvm-svn: 182080