| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 192924
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit implements the correct lowering of the
COPY_STRUCT_BYVAL_I32 pseudo-instruction for thumb1 targets.
Previously, the lowering of COPY_STRUCT_BYVAL_I32 generated the
post-increment forms of ldr/ldrh/ldrb instructions. Thumb1 does not
have the post-increment form of these instructions so the generated
assembly contained invalid instructions.
Passing the generated assembly to gcc caused it to complain with an
error like this:
Error: cannot honor width suffix -- `ldrb r3,[r0],#1'
and the integrated assembler would generate an object file with an
invalid instruction encoding.
This commit contains a small test case that demonstrates the problem
with thumb1 targets as well as an expanded test case that more
throughly tests the lowering of byval struct passing for arm,
thumb1, and thumb2 targets.
llvm-svn: 192916
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit refactors the lowering of the COPY_STRUCT_BYVAL_I32
pseudo-instruction in the ARM backend. We introduce a new helper
class that encapsulates all of the operations needed during the
lowering. The operations are implemented for each subtarget in
different subclasses. Currently only arm and thumb2 subtargets are
supported.
This refactoring was done to easily implement support for thumb1
subtargets. This initial patch does not add support for thumb1, but
is only a refactoring. A follow on patch will implement the support
for thumb1 subtargets.
No intended functionality change.
llvm-svn: 192915
|
|
|
|
|
|
|
|
|
|
|
|
| |
All of the Core API functions have versions which accept explicit context, in
addition to ones which work on global context. This commit adds functions
which accept explicit context to the Target API for consistency.
Patch by Peter Zotov
Differential Revision: http://llvm-reviews.chandlerc.com/D1912
llvm-svn: 192913
|
|
|
|
| |
llvm-svn: 192910
|
|
|
|
|
|
|
|
| |
class. The instruction class includes the signed saturating doubling
multiply-add long, signed saturating doubling multiply-subtract long, and
the signed saturating doubling multiply long instructions.
llvm-svn: 192908
|
|
|
|
| |
llvm-svn: 192907
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 192906
|
|
|
|
| |
llvm-svn: 192895
|
|
|
|
|
|
| |
code. No functionality change.
llvm-svn: 192894
|
|
|
|
|
|
|
|
| |
These were present in a previous version of the MSA spec but are not
present in the published version. There is no hardware that uses these
instructions.
llvm-svn: 192888
|
|
|
|
|
|
| |
E.g. (and (sra (i32 x) 31) 2) -> (and (srl (i32 x) 30) 2).
llvm-svn: 192884
|
|
|
|
|
|
|
|
|
|
|
|
| |
When canonicalizing dags according to the rule
(shl (zext (shr X, c1) ), c1) ==> (zext (shl (shr X, c1), c1))
remember to add the new shl dag to the DAGCombiner worklist of nodes.
If we don't explicitly add it to the worklist of nodes to visit, we
may not trigger later on the rule that folds the shift left + logical
shift right into a AND instruction with bitmask.
llvm-svn: 192883
|
|
|
|
|
|
| |
Switch to sign-extension in r192575 caused 7% perf loss on 482.sphinx3.
llvm-svn: 192882
|
|
|
|
|
|
|
|
|
|
|
|
| |
Error handling code for raw_fd_ostream constructor is present, but
never used, because formatted_raw_ostream will always assert on closed
fd's before.
Patch by Peter Zotov
Differential Revision: http://llvm-reviews.chandlerc.com/D1909
llvm-svn: 192881
|
|
|
|
|
|
|
|
| |
Define these three instructions in alphabetical order (like the rest of the
file).
No functional change.
llvm-svn: 192880
|
|
|
|
|
|
|
|
| |
Solves http://llvm.org/bugs/show_bug.cgi?id=17507
Committed on behalf of alon.mishne@intel.com
llvm-svn: 192879
|
|
|
|
|
|
|
|
|
|
|
|
| |
If no targets are registered, LLVMGetFirstTarget currently fails with
an assertion. This patch makes it return NULL instead, similarly to
how LLVMGetNextTarget would.
Patch by Peter Zotov
Differential Revision: http://llvm-reviews.chandlerc.com/D1908
llvm-svn: 192878
|
|
|
|
|
|
|
| |
If a function has no_sanitize_thread attribute,
do not instrument memory accesses in it.
llvm-svn: 192871
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Consider the following:
typedef unsigned short ushort4U __attribute__((ext_vector_type(4),
aligned(2)));
typedef unsigned short ushort4 __attribute__((ext_vector_type(4)));
typedef unsigned short ushort8 __attribute__((ext_vector_type(8)));
typedef int int4 __attribute__((ext_vector_type(4)));
int4 __bbase_cvt_int(ushort4 v) {
ushort8 a;
a.lo = v;
return _mm_cvtepu16_epi32(a);
}
This generates the, not unreasonable, IR:
define <4 x i32> @foo0(double %v.coerce) nounwind ssp {
%tmp = bitcast double %v.coerce to <4 x i16>
%tmp1 = shufflevector <4 x i16> %tmp, <4 x i16> undef, <8 x i32> <i32
%0, i32 1, i32 2, i32 3, i32 undef, i32 undef, i32 undef, i32 undef>
%tmp2 = tail call <4 x i32> @llvm.x86.sse41.pmovzxwd(<8 x i16> %tmp1)
ret <4 x i32> %tmp2
}
The problem is when type legalization gets hold of the v4i16. It
legalizes that by spilling to the stack, then doing a zero-extending
load. Things go even more silly from there, ending up with something
like:
_foo0:
movsd %xmm0, -8(%rsp) <== Spill to the stack.
movq -8(%rsp), %xmm0 <== Reload it right back out.
pmovzxwd %xmm0, %xmm1 <== Here's what we actually asked for.
pblendw $1, %xmm1, %xmm0 <== We don't need this at all
pmovzxwd %xmm0, %xmm0 <== We already did this
ret
The v8i8 to v8i16 zext intrinsic gives even worse results, with two
table lookups via pshufb instructions(!!).
To avoid all that, we can move the bitcasting until after we've formed
the wider (legal) vector type. Then our normal codegen flows along
nicely and we get the expected:
_foo0:
pmovzxwd %xmm0, %xmm0
ret
rdar://15245794
llvm-svn: 192866
|
|
|
|
|
|
|
|
|
|
|
| |
like C++ should be the fully qualified names for the type.
Add a routine that does a language specific context walk to build
up the qualified name and use it when we add types/names to the
tables. Expand the gnu pubnames testcase as it's the most complex
to make sure that qualified types are also being added.
llvm-svn: 192865
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I expose the API with some caveats:
- The C++ API involves a traditional void* opaque pointer for the fatal
error callback. The C API doesn’t do this. I don’t think that the void*
opaque pointer makes any sense since this is a global callback - there will
only be one of them. So if you need to pass some data to your callback,
just put it in a global variable.
- The bindings will ignore the gen_crash_diag boolean. I ignore it because
(1) I don’t know what it does, (2) it’s not documented AFAIK, and (3) I
couldn’t imagine any use for it. I made the gut call that it probably
wasn’t important enough to expose through the C API.
llvm-svn: 192864
|
|
|
|
|
|
| |
No functionality changes.
llvm-svn: 192863
|
|
|
|
|
|
|
| |
if they're a declaration, otherwise they're owned by the compile
unit.
llvm-svn: 192861
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The reason this got reverted was that the @feat.00 symbol which was emitted
for every TU became quoted, and on cygwin/mingw we use the gas assembler which
couldn't handle the quotes.
This commit fixes the problem by only emitting @feat.00 for win32, where we use
clang -cc1as to assemble. gas would just drop this symbol anyway, so there is no
loss there.
With @feat.00 gone, there shouldn't be quoted symbols showing up on cygwin since
it uses the Itanium ABI, which doesn't put these funny characters in symbols.
> Because of win32 mangling, we produce symbol and section names with
> funny characters in them, most notably @ characters.
>
> MC would choke on trying to parse its own assembly output. This patch addresses
> that by:
>
> - Making @ trigger quoting of symbol names
> - Also quote section names in the same way
> - Just parse section names like other identifiers (to allow for quotes)
> - Don't assume @ signifies a symbol variant if it is in a string.
llvm-svn: 192859
|
|
|
|
| |
llvm-svn: 192856
|
|
|
|
|
|
|
| |
This allows us to produce the same hash as GCC for at least some simple
examples.
llvm-svn: 192855
|
|
|
|
|
|
|
|
|
|
| |
The C API currently allows to dump values (LLVMDumpValue), but a similar method for types was not exported.
Patch by Peter Zotov
Differential Revision: http://llvm-reviews.chandlerc.com/D1911
llvm-svn: 192852
|
|
|
|
| |
llvm-svn: 192843
|
|
|
|
| |
llvm-svn: 192842
|
|
|
|
| |
llvm-svn: 192840
|
|
|
|
|
|
| |
as we don't actually use it to emit any code yet.
llvm-svn: 192837
|
|
|
|
| |
llvm-svn: 192836
|
|
|
|
|
|
|
|
|
| |
bulldozer and piledriver. Support for the instruction itself seems to have
already been added in r178040.
Differential Revision: http://llvm-reviews.chandlerc.com/D1933
llvm-svn: 192828
|
|
|
|
|
|
| |
Patch by Stephen Checkoway.
llvm-svn: 192827
|
|
|
|
|
|
| |
This should fix the ATOM buildbot failing on break-avx-dep.ll.
llvm-svn: 192824
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes a small mistake in MCDataAtom::addData() where it doesn't ever
call remap():
- if (Data.size() > Begin - End - 1)
+ if (Data.size() > End + 1 - Begin)
remap(Begin, End + 1);
This is currently not visible because of another bug is the disassembler, so
the patch includes a unit test.
Patch by Stephen Checkoway.
llvm-svn: 192823
|
|
|
|
|
|
|
|
|
| |
Like LLVMDumpModule but returns the string (that needs to be freed
with LLVMDisposeMessage) instead of printing it to stderr.
Differential Revision: http://llvm-reviews.chandlerc.com/D1941
llvm-svn: 192821
|
|
|
|
|
|
|
|
|
|
| |
radar://15231682
Reapply r192799,
http://lab.llvm.org:8011/builders/lldb-x86_64-debian-clang/builds/8226
showed that the bot is still broken even with this out.
llvm-svn: 192820
|
|
|
|
|
|
| |
This speculatively reverts commit 192799. It might have broken a linux buildbot.
llvm-svn: 192816
|
|
|
|
|
|
|
|
|
|
| |
We were calling llvm_unreachable() when failing to optimize the
branch into if case. However, it is still possible for us
to structurize the CFG by duplicating blocks even if this optimization
fails.
Reviewed-by: Vincent Lejeune<vljn at ovi.com>
llvm-svn: 192813
|
|
|
|
|
| |
Reviewed-by: Vincent Lejeune<vljn at ovi.com>
llvm-svn: 192812
|
|
|
|
|
|
| |
Patch by Dmitry Stogov
llvm-svn: 192809
|
|
|
|
| |
llvm-svn: 192805
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this patch we would assert when building llvm as multiple shared
libraries (cmake's BUILD_SHARED_LIBS). The problem was the line
if (T.AsmStreamerCtorFn == Target::createDefaultAsmStreamer)
which returns false because of -fvisibility-inlines-hidden. It is easy
to fix just this one case, but I decided to try to also make the
registration more strict. It looks like the old logic for ignoring
followup registration was just a temporary hack that outlived its
usefulness.
This patch converts the ifs to asserts, fixes the few cases that were
registering twice and makes sure all the asserts compare with null.
Thanks for Joerg for reporting the problem and reviewing the patch.
llvm-svn: 192803
|
|
|
|
|
|
| |
value and unsigned saturating accumulate of signed value instructions.
llvm-svn: 192800
|
|
|
|
|
|
| |
radar://15231682
llvm-svn: 192799
|
|
|
|
|
|
|
|
|
|
|
| |
constant.
This happens e.g. with <2 x i64> -1 on x86_32. It cannot be generated directly
because i64 is illegal. It would be nice if getNOT would handle this
transparently, but I don't see a way to generate a legal constant there right
now. Fixes PR17487.
llvm-svn: 192795
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Given a global array G[N], which is declared in this CU and has static initializer
avoid instrumenting accesses like G[i], where 'i' is a constant and 0<=i<N.
Also add a bit of stats.
This eliminates ~1% of instrumentations on SPEC2006
and also partially helps when asan is being run together with coverage.
Reviewers: samsonov
Reviewed By: samsonov
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1947
llvm-svn: 192794
|
|
|
|
|
|
|
| |
The input to an RxSBG operation can be narrower as long as the upper bits
are don't care. This fixes a FIXME added in r192783.
llvm-svn: 192790
|