| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
| |
Due to the execution order of doFinalization functions, the GC information were
deleted before AsmPrinter::doFinalization was executed. Thus, the
GCMetadataPrinter::finishAssembly was never called.
The patch fixes that by moving the code of the GCInfoDeleter::doFinalization to
Printer::doFinalization.
llvm-svn: 175528
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A vectorized sitfp on doubles will get scalarized to a sequence of an
extract_element of <2 x i32>, a bitcast to f32 and a sitofp.
Due to the the extract_element, and the bitcast we will uneccessarily generate
moves between scalar and vector registers.
The patch fixes this by using a COPY_TO_REGCLASS and a EXTRACT_SUBREG to extract
the element from the vector instead.
radar://13191881
llvm-svn: 175520
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch makes asan instrument memory accesses with unusual sizes (e.g. 5 bytes or 10 bytes), e.g. long double or
packed structures.
Instrumentation is done with two 1-byte checks
(first and last bytes) and if the error is found
__asan_report_load_n(addr, real_size) or
__asan_report_store_n(addr, real_size)
is called.
Also, call these two new functions in memset/memcpy
instrumentation.
asan-rt part will follow.
llvm-svn: 175507
|
|
|
|
|
|
| |
BtnezT8SltiX16, BtnezT8SltiuX16 .
llvm-svn: 175486
|
|
|
|
| |
llvm-svn: 175476
|
|
|
|
| |
llvm-svn: 175474
|
|
|
|
|
|
| |
library call.
llvm-svn: 175470
|
|
|
|
| |
llvm-svn: 175460
|
|
|
|
|
|
|
|
| |
If the memcpy has an odd length with an alignment of 2, this would incorrectly
assert on the last 1 byte copy.
rdar://13202135
llvm-svn: 175459
|
|
|
|
| |
llvm-svn: 175457
|
|
|
|
| |
llvm-svn: 175446
|
|
|
|
|
|
| |
long double will require a more general solution
llvm-svn: 175442
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Profiling tests *do* need a JIT. They'll pass if a cross-compiler targetting
AArch64 by default has been built, but fail if a native AArch64 compiler has
been build. Therefore XFAIL is inappropriate and we mark them unsupported.
ExecutionEngine tests are JIT by definition, they should also be unsupported.
Transforms/LICM only uses the interpreter to check the output is still sane
after optimisation. It can be switched to use an interpreter.
llvm-svn: 175433
|
|
|
|
| |
llvm-svn: 175420
|
|
|
|
| |
llvm-svn: 175417
|
|
|
|
| |
llvm-svn: 175416
|
|
|
|
|
|
|
|
|
|
| |
This expansion will be moved to expandISelPseudos as soon as I can figure
out how to do that. There are other instructions which use this
ExpandFEXT_T8I816_ins and as soon as I have finished expanding them all,
I will delete the macro asm string text so it has no way to be used
in the future.
llvm-svn: 175413
|
|
|
|
|
|
|
| |
These instructions are not targeted by the compiler but it is needed for
the MC layer.
llvm-svn: 175407
|
|
|
|
|
|
|
| |
This instruction is not targeted by the compiler but it is needed for the
MC layer.
llvm-svn: 175406
|
|
|
|
|
|
|
| |
These instructions are not targeted by the compiler but they are
needed for the MC layer.
llvm-svn: 175404
|
|
|
|
|
|
|
| |
These instructions are not targeted by the compiler but they are
needed for the MC layer.
llvm-svn: 175403
|
|
|
|
| |
llvm-svn: 175401
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes PR15289. This bug was introduced (recently) in r175215; collecting
all std::vector references for candidate pairs to delete at once is invalid
because subsequent lookups in the owning DenseMap could invalidate the
references.
bugpoint was able to reduce a useful test case. Unfortunately, because whether
or not this asserts depends on memory layout, this test case will sometimes
appear to produce valid output. Nevertheless, running under valgrind will
reveal the error.
llvm-svn: 175397
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(or (bool?A:B),(bool?C:D)) --> (bool?(or A,C):(or B,D))
By the time the OR is visited, both the SELECTs have been visited and not
optimized and the OR itself hasn't been transformed so we do this transform in
the hopes that the new ORs will be optimized.
The transform is explicitly disabled for vector-selects until "codegen matures
to handle them better".
Patch by Muhammad Tauqir!
llvm-svn: 175380
|
|
|
|
|
|
|
|
| |
GNU as rejects them and there are configure scripts in the wild that check if
the assembler rejects ".align 3" to determine whether the alignment is in bytes
or powers of two.
llvm-svn: 175360
|
|
|
|
|
|
| |
Also fix one test by changing "vpermilps" to "vpshufd".
llvm-svn: 175357
|
|
|
|
|
|
| |
new features.
llvm-svn: 175336
|
|
|
|
|
|
|
|
|
|
|
| |
If the frame pointer is omitted, and any stack changes occur in the inline
assembly, e.g.: "pusha", then any C local variable or C argument references
will be incorrect.
I pass no judgement on anyone who would do such a thing. ;)
rdar://13218191
llvm-svn: 175334
|
|
|
|
|
|
| |
so.
llvm-svn: 175327
|
|
|
|
| |
llvm-svn: 175322
|
|
|
|
|
|
|
| |
When we're recalculating the feature set of the subtarget, we need to have the
ivars in their initial state.
llvm-svn: 175320
|
|
|
|
|
|
|
|
|
|
|
|
| |
With bundle alignment, instructions all get their own MCFragments
(unless they are in a bundle-locked group). For instructions with
fixups, this is an MCDataFragment. Emitting actual data (e.g. for
.long) attempts to re-use MCDataFragments, which we don't want int
this case since it leads to fragments which exceed the bundle size.
So, don't reuse them in this case.
Also adds a test and fixes some formatting.
llvm-svn: 175316
|
|
|
|
|
|
| |
metadata, sorry.
llvm-svn: 175311
|
|
|
|
|
|
|
|
|
|
|
|
| |
- add sincos to runtime library if target triple environment is GNU
- added canCombineSinCosLibcall() which checks that sincos is in the RTL and
if the environment is GNU then unsafe fpmath is enabled (required to
preserve errno)
- extended sincos-opt lit test
Reviewed by: Hal Finkel
llvm-svn: 175283
|
|
|
|
|
|
|
|
|
| |
It enables to work with a smaller constant, which is target friendly for those which can compare to immediates.
It also avoids inserting a shift in favor of a trunc, which can be free on some targets.
This used to work until LLVM-3.1, but regressed with the 3.2 release.
llvm-svn: 175270
|
|
|
|
|
|
| |
https://code.google.com/p/address-sanitizer/issues/detail?id=151
llvm-svn: 175266
|
|
|
|
|
|
|
|
| |
This implements the review suggestion to simplify the AArch64 backend. If we
later discover that we *really* need the extra complexity of the
ConstantIslands pass for performance reasons it can be resurrected.
llvm-svn: 175258
|
|
|
|
|
|
|
|
| |
In the near future litpools will be in a different section, which means that
any access to them is at least two instructions. This makes the case for a
movz/movk pair (if total offset <= 32-bits) even more compelling.
llvm-svn: 175257
|
|
|
|
| |
llvm-svn: 175252
|
|
|
|
|
|
| |
This reverts commit 58f20a3cbfca7384fe5e25e095f18572736a4792.
llvm-svn: 175249
|
|
|
|
|
|
| |
This reverts commit 997c6516ca161073a1d516ebca7c0ca7722f64e2.
llvm-svn: 175248
|
|
|
|
| |
llvm-svn: 175238
|
|
|
|
|
|
|
| |
not matter but makes it more gcc compatible which avoids possible subtle
problems. Also, turned back on a disabled check in helloworld.ll.
llvm-svn: 175237
|
|
|
|
| |
llvm-svn: 175236
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
assembler should also accept a two arg form, as the docuemntation specifies that
the first (destination) register is optional.
This patch uses TwoOperandAliasConstraint to add the two argument form.
It also fixes an 80-column formatting problem in:
test/MC/ARM/neon-bitwise-encoding
<rdar://problem/12909419> Clang rejects ARM NEON assembly instructions
llvm-svn: 175221
|
|
|
|
| |
llvm-svn: 175200
|
|
|
|
|
|
| |
-feature flag, instructions definitions, test cases
llvm-svn: 175196
|
|
|
|
| |
llvm-svn: 175190
|
|
|
|
|
|
|
|
| |
inline asm with 64-bit data on ARM
Update test case to use -mtriple=arm-linux-gnueabi
llvm-svn: 175186
|
|
|
|
|
|
|
|
|
| |
It fixes around 100 tfb piglit tests and 16 glean tests.
NOTE: This is a candidate for the Mesa stable branch.
Reviewed-by: Tom Stellard <thomas.stellard at amd.com>
llvm-svn: 175183
|