Dot4 now uses 8 scalar operands instead of 2 vectors one which allows register
coalescer to remove some unneeded COPY.
This patch also defines some structures/functions that can be used to handle
every vector instructions (CUBE, Cayman special instructions...) in a similar
fashion.
llvm-svn: 182126
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
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
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
- 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
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
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
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
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
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
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
Vincent Lejeune