| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
EltsFromConsecutiveLoads
This patch adds support for trailing zero elements to VZEXT_LOAD loads (and checks that no zero elts occur within the consecutive load).
It also generalizes the 64-bit VZEXT_LOAD load matching to work for loads other than 2x32-bit loads.
After this patch it will also be easier to add support for other basic load patterns like 32-bit VZEXT_LOAD loads, PMOVZX and subvector load insertion.
Differential Revision: http://reviews.llvm.org/D16217
llvm-svn: 258798
|
| |
|
|
| |
llvm-svn: 258797
|
| |
|
|
| |
llvm-svn: 258796
|
| |
|
|
| |
llvm-svn: 258795
|
| |
|
|
| |
llvm-svn: 258794
|
| |
|
|
|
|
| |
Their opcodes are used as part of the VEX prefix in 64-bit mode. Clearly the disassembler implicitly decoded them as AVX instructions in 64-bit mode, but I think the AsmParser would have encoded them.
llvm-svn: 258793
|
| |
|
|
|
|
| |
This new code should be logically equivalent to the previous code.
llvm-svn: 258792
|
| |
|
|
| |
llvm-svn: 258791
|
| |
|
|
| |
llvm-svn: 258790
|
| |
|
|
|
|
|
|
|
|
| |
Make comments and indentation more consistent.
Rearrange a few things to be in a more consistent order,
such as organizing subtarget features from those describing
an actual device property, and those used as options.
llvm-svn: 258789
|
| |
|
|
|
|
|
|
| |
Old intrinsics were forcing these, but they have now all
been removed. This fixes large i8 vector operations generally
being broken.
llvm-svn: 258788
|
| |
|
|
|
|
|
|
|
|
|
| |
I did my best to try to update all the uses in tests that
just happened to use the old ones to the newer intrinsics.
I'm not sure I got all of the immediate operand conversions
correct, since the value seems to have been ignored by the
old pattern but I don't think it really matters.
llvm-svn: 258787
|
| |
|
|
|
|
|
| |
More cleanup to try to get all intrinsics using the correct
amdgcn prefix that are as close to the instruction as possible.
llvm-svn: 258786
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some of the special intrinsics now that now correspond to a instruction
also have special setting of some registers, e.g. llvm.SI.sendmsg sets
m0 as well as use s_sendmsg. Using these explicit register intrinsics
may be a better option.
Reading the exec mask and others may be useful for debugging. For this
I'm not sure this is entirely correct because we would want this to
be convergent, although it's possible this is already treated
sufficently conservatively.
llvm-svn: 258785
|
| |
|
|
| |
llvm-svn: 258784
|
| |
|
|
|
|
| |
Also move into backend intrinsics to discourage use of the old name.
llvm-svn: 258783
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix arc patch fuzz error.
Summary:
Support for the pipe built-in functions for OpenCL 2.0.
The pipe builtin functions may have infinite kinds of element types, one approach
would be to just generate calls that would always use generic types such as void*.
This patch is based on bader's opencl support patch on SPIR-V branch.
Reviewers: Anastasia, pekka.jaaskelainen
Subscribers: keryell, bader, cfe-commits
Differential Revision: http://reviews.llvm.org/D15914
llvm-svn: 258782
|
| |
|
|
|
|
|
|
| |
These calls return their first argument, but because LLVM uses an intrinsic
with a void return type, they can't use the returned attribute. Generalize
the store results pass to optimize these calls too.
llvm-svn: 258781
|
| |
|
|
| |
llvm-svn: 258780
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D16534
llvm-svn: 258779
|
| |
|
|
|
|
|
|
|
| |
Move the function to get a macro name from DiagnosticRenderer.cpp to Lexer.cpp
so that other files can use it. Lexer now has two functions to get the
immediate macro name, the newly added one is better for diagnostic purposes.
Make -Wnull-conversion use this function for better NULL macro detection.
llvm-svn: 258778
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a recommit of r258620 which causes PR26293.
The original message:
Now LIR can turn following codes into memset:
typedef struct foo {
int a;
int b;
} foo_t;
void bar(foo_t *f, unsigned n) {
for (unsigned i = 0; i < n; ++i) {
f[i].a = 0;
f[i].b = 0;
}
}
void test(foo_t *f, unsigned n) {
for (unsigned i = 0; i < n; i += 2) {
f[i] = 0;
f[i+1] = 0;
}
}
llvm-svn: 258777
|
| |
|
|
| |
llvm-svn: 258776
|
| |
|
|
|
|
|
| |
This reverts commit r258773, it broke the build bots:
http://bb.pgr.jp/builders/cmake-clang-x86_64-linux/builds/43853
llvm-svn: 258775
|
| |
|
|
|
|
|
|
| |
This improves compile time of Function.cpp from 57s to 37s for me
locally. Intrinsic IDs are cached on the Function object, so this
shouldn't regress performance.
llvm-svn: 258774
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Support for the pipe built-in functions for OpenCL 2.0.
The pipe builtin functions may have infinite kinds of element types, one approach
would be to just generate calls that would always use generic types such as void*.
This patch is based on bader's opencl support patch on SPIR-V branch.
Reviewers: Anastasia, pekka.jaaskelainen
Subscribers: keryell, bader, cfe-commits
Differential Revision: http://reviews.llvm.org/D15914
llvm-svn: 258773
|
| |
|
|
|
|
|
| |
This test is failing on a bot for reasons that are unclear to me.
Reverting for now...
llvm-svn: 258772
|
| |
|
|
|
|
| |
As recommended by Justin.
llvm-svn: 258771
|
| |
|
|
|
|
| |
No functional change is intended.
llvm-svn: 258769
|
| |
|
|
|
|
|
|
|
|
| |
Per C++14 [class.virtual]p8, it is OK for the return type's class type
to be incomplete so long as the return type is the same between the base
and complete classes.
This fixes PR26297.
llvm-svn: 258768
|
| |
|
|
| |
llvm-svn: 258767
|
| |
|
|
| |
llvm-svn: 258766
|
| |
|
|
|
|
|
|
| |
This is another example of a test that was looking for the thread
at index 0 instead of requesting the thread that was stopped at
the created breakpoint. This assumption isn't true on Windows 10.
llvm-svn: 258764
|
| |
|
|
|
|
|
|
|
| |
lldbinline tests previously did not run correctly unless there was already a
Makefile for them. This was because the syntax of the emitted Makefile made the
default make rule be the "cleanup" rule, which is pretty unhelpful. Now the
default rule is the one included from Makefile.rules, which is much better.
llvm-svn: 258763
|
| |
|
|
|
|
|
|
|
|
|
| |
__GetExceptionInfo triggered Sema::LazilyCreateBuiltin which tries to
create a non-templated function decl. This is unnecessary and
ill-advised, there is no need for us to create a declaration for such a
builtin.
This fixes PR26298.
llvm-svn: 258762
|
| |
|
|
| |
llvm-svn: 258761
|
| |
|
|
| |
llvm-svn: 258760
|
| |
|
|
|
|
|
|
|
|
|
| |
Previously we were writing in the default encoding, which depends
on the operating system and is not guaranteed to be unicode aware.
On Python 3, this would lead to a situation where writing unicode
text to the log file generates an exception. The fix here is to
write session logs using the proper encoding, which incidentally
fixes another test, so xfail is removed from that.
llvm-svn: 258759
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes the regression of several tests on Windows after rL258621.
The root problem is that ObjectFilePECOFF was not setting type information for the symbols, and the new CL rejects symbols without type information, breaking functionality like thread step-over.
The fix sets the type information for functions (and creates a TODO for other types).
Along the way, I fixed some typos and formatting that made the code I was debugging harder to understand.
In the long run, we should consider replacing most of ObjectFilePECOFF with the COFF parsing code from LLVM.
Differential Revision: http://reviews.llvm.org/D16563
llvm-svn: 258758
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Step one towards using a simple binary search to lookup intrinsic IDs
instead of our crazy table generated switch+memcmp+startswith code that
makes Function.cpp take about a minute to compile. See PR24785 and
PR11951 for why we should do this.
The X86 backend contains tables that need to be sorted on intrinsic ID,
so reorder those.
llvm-svn: 258757
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These two functions are hard to reason about. This commit makes the code
more comprehensible:
- Use four distinct variables (OldIdxIn, OldIdxOut, NewIdxIn, NewIdxOut)
with a fixed value instead of a changing iterator I that points to
different things during the function.
- Remove the early explanation before the function in favor of more
detailed comments inside the function. Should have more/clearer comments now
stating which conditions are tested and which invariants hold at
different points in the functions.
The behaviour of the code was not changed.
I hope that this will make it easier to review the changes in
http://reviews.llvm.org/D9067 which I will adapt next.
Differential Revision: http://reviews.llvm.org/D16379
llvm-svn: 258756
|
| |
|
|
| |
llvm-svn: 258755
|
| |
|
|
| |
llvm-svn: 258754
|
| |
|
|
|
|
|
|
|
| |
This does not solve the problem that we call isGnuIFunc function
both from RelocationSection and from the Writer::scanRelocs, but
this at least should improve readability. I'm taking an incremental
approach to reduce complexity.
llvm-svn: 258753
|
| |
|
|
| |
llvm-svn: 258752
|
| |
|
|
|
|
|
|
|
|
| |
In Python 3, whitespace inconsistences are errors. This synthetic
provider had mixed tabs and spaces, as well as inconsistent
indentation widths. This led to the file not being imported,
and naturally the test failing. No functional change here, just
whitespace.
llvm-svn: 258751
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For historic reasons, the behavior of .align differs between targets.
Fortunately, there are alternatives, .p2align and .balign, which make the
interpretation of the parameter explicit, and which behave consistently across
targets.
This patch teaches MC to use .p2align instead of .align, so that people reading
code for multiple architectures don't have to remember which way each platform
does its .align directive.
Differential Revision: http://reviews.llvm.org/D16549
llvm-svn: 258750
|
| |
|
|
| |
llvm-svn: 258749
|
| |
|
|
| |
llvm-svn: 258748
|
| |
|
|
| |
llvm-svn: 258747
|