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

This means adding an extra edge from the 'if' to the condition,
which aesthetically looks more pleasing.

llvm-svn: 182079

for a nested call.  This matches what we do with the first stack frame.

llvm-svn: 182078

only if they are relative. This removes the FIXME when the
relocations are being emitted and checks if the relocation
is relative and only then populates the addend information.

I couldnt add a testcase for this as llvm-readobj lacks     
functionality of printing dynamic relocations.              

When the functionality is added, remove the commented lines
from elf/ifunc.test to test functionality.

llvm-svn: 182077

This patch splits X86_64Target specific code so that 
the dynamic atoms and the Relocation handlers are in seperate 
files for easier maintenace. The files are sure to grow and this 
makes it easier to work with.

* There is no change in functionality *

llvm-svn: 182076

llvm-svn: 182075

llvm-svn: 182074

instantiate the inherited constructor template and mark that as the constructor
which the instantiated specialization is inheriting. This fixes a
crash-on-valid when trying to compute the exception specification of a
specialization of the inheriting constructor.

llvm-svn: 182072

The analyzer can't see the reference count for shared_ptr, so it doesn't
know whether a given destruction is going to delete the referenced object.
This leads to spurious leak and use-after-free warnings.

For now, just ban destructors named '~shared_ptr', which catches
std::shared_ptr, std::tr1::shared_ptr, and boost::shared_ptr.

PR15987

llvm-svn: 182071

AST dumping: if a declaration has an uncomputed or uninstantiated exception specification, include that in the dump.

llvm-svn: 182070

Comment out ObjectFileELF::GetModuleSpecifications() function until I can debug where it's causing tests to fail.

llvm-svn: 182069

rdar://problem/13916722

llvm-svn: 182068

"source list -n <func>" can now show more than one location that matches a function name. It will unique multiple of the same source locations so they don't get displayed. It also handles inline functions correctly.

llvm-svn: 182067

Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression.

llvm-svn: 182066

Implement ObjectFileELF::GetModuleSpecifications(), and add PlatformLinux code to deal with unknown arch properties.

CR: Greg Clayton
llvm-svn: 182065

llvm-svn: 182064

llvm-svn: 182063

radar://problem/13865940

llvm-svn: 182062

llvm-svn: 182061