| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
common code. NFCI.
Prep work for PR39467.
llvm-svn: 347067
|
|
|
|
| |
llvm-svn: 347066
|
|
|
|
|
|
|
| |
This fixes PR39669.
https://bugs.llvm.org/show_bug.cgi?id=39669
llvm-svn: 347065
|
|
|
|
|
|
|
| |
Use the newly available space in the bit-fields of Stmt.
This saves 8 bytes per CXXThisExpr.
llvm-svn: 347064
|
|
|
|
|
|
|
| |
Use the newly available space in the bit-fields of Stmt.
This saves one pointer per CXXNullPtrLiteralExpr.
llvm-svn: 347063
|
|
|
|
|
|
|
| |
Use the newly available space in Stmt.
This saves 8 bytes per CXXBoolLiteralExpr.
llvm-svn: 347062
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is for supporting custom stack map formats, where the
custom printer can access the stack map data.
Patch by Cherry Zhang <cherryyz@google.com>.
Related: https://reviews.llvm.org/D53892
Reviewers: thanm, apilipenko
Reviewed By: apilipenko
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D54224
llvm-svn: 347061
|
|
|
|
|
|
|
|
| |
These are baseline tests for D54532.
Patch based on the original tests by:
@nikic (Nikita Popov)
llvm-svn: 347060
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added references to the addr spaces deduction and enabled
CL2.0 features (program scope variables and storage class
qualifiers) to work in C++ mode too.
Fixed several address space conversion issues in CodeGen
for references.
Differential Revision: https://reviews.llvm.org/D53764
llvm-svn: 347059
|
|
|
|
| |
llvm-svn: 347058
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This saves about 3 redundant gigabytes from the Objective-C test build
directories. Tests that must do unsavory things with the LLDB clang
module cache, already specify a per-test module cache in their .py
test instructions.
<rdar://problem/36002081>
Differential Revision: https://reviews.llvm.org/D54602
llvm-svn: 347057
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Just to be safe, up until now each test used its own Clang module
cache directory. Since the compiler within one testsuite doesn't
change it is just as safe to share a clang module directory inside the
LLDB test build directory. This saves us from compiling tens of
gigabytes of redundant Darwin and Foundation .pcm files and also
speeds up running the test suite quite significantly.
rdar://problem/36002081
Differential Revision: https://reviews.llvm.org/D54601
llvm-svn: 347056
|
|
|
|
|
|
|
|
| |
This is a baseline test for D54631.
Patch by:
@nikic (Nikita Popov)
llvm-svn: 347055
|
|
|
|
|
|
| |
Only combineX86ShufflesRecursively needs this limit.
llvm-svn: 347054
|
|
|
|
|
|
|
| |
Expanded the readability-inconsistent-declaration-parameter-name-macros.cpp to
check notes and added a test with pasted tokens.
llvm-svn: 347053
|
|
|
|
|
|
|
|
|
|
| |
I also kept the original "vague" documentation that saying that users are
responsible for not breaking us. This doesn't mean anything because there's
no way they can actually enforce that unless we restrict ourselves to a
specific naming scheme, but I left the documentation because it acts as a
good warning and gives us more leeway.
llvm-svn: 347052
|
|
|
|
| |
llvm-svn: 347051
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
StructRet attribute is not allowed in vararg calls. The statepoint
intrinsic is vararg, but the wrapped function may be not. Allow
calls of statepoint with StructRet arg, as long as the wrapped
function is not vararg.
Reviewers: thanm, anna
Reviewed By: anna
Subscribers: anna, llvm-commits
Differential Revision: https://reviews.llvm.org/D53602
llvm-svn: 347050
|
|
|
|
|
|
|
|
| |
This is a follow-up to r346715. Use PRIx64 to formatted print of 64-bit
value in the `DWARFDebugLoclists::LocationList::dump` to escape problem
on big-endian hosts.
llvm-svn: 347049
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
As discussed in previous review, and noted in the FIXME, if `X` is actually an `lshr Y, Z` (logical!),
we can fold the `Z` into 'control`, and let the `BEXTR` do this too.
We could just insert those 8 bits of shift amount into control,
but it is better to instead zero-extend them, and 'or' them in place.
We can only do this for `lshr`, not `ashr`, because we do not know that the mask cover only the bits of `Y`,
and not any of the sign-extended bits.
The obvious question is, is this actually legal to do?
I believe it is. Relevant quotes, from `Intel® 64 and IA-32 Architectures Software Developer’s Manual`, `BEXTR — Bit Field Extract`:
* `Bit 7:0 of the second source operand specifies the starting bit position of bit extraction.`
* `A START value exceeding the operand size will not extract any bits from the second source operand.`
* `Only bit positions up to (OperandSize -1) of the first source operand are extracted.`
* `All higher order bits in the destination operand (starting at bit position LENGTH) are zeroed.`
* `The destination register is cleared if no bits are extracted.`
FIXME: if we can do this, i wonder if we should prefer `BEXTR` over `BZHI` in such cases.
Reviewers: RKSimon, craig.topper, spatel, andreadb
Reviewed By: RKSimon, craig.topper, andreadb
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D54095
llvm-svn: 347048
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Remove extra `;` to eliminate the following pedantic warning.
```
warning: extra ';' [-Wpedantic]
```
Reviewers: shafik
Reviewed By: shafik
Subscribers: abidh, lldb-commits
Differential Revision: https://reviews.llvm.org/D54528
llvm-svn: 347047
|
|
|
|
|
|
| |
This was removed in r336666, but accidentally re-added in r346984.
llvm-svn: 347046
|
|
|
|
|
|
|
|
| |
match. NFCI.
Use the same variable names etc.
llvm-svn: 347045
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is our goal. It has a non-zero rick, but so far we haven't see any
collision (externally and internally).
Reviewers: sammccall
Subscribers: ilya-biryukov, ioeric, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D54622
llvm-svn: 347044
|
|
|
|
|
|
|
|
|
|
|
|
| |
The RISC-V ISA manual was updated on 2018-11-07 (commit 00557c3) to define a
new compressed instruction format, RVC format CA (no actual instruction
encodings were changed). This patch updates the RISC-V backend to define the
new format, and to use it in the relevant instructions.
Differential Revision: https://reviews.llvm.org/D54302
Patch by Luís Marques.
llvm-svn: 347043
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit introduces support for materialising 64-bit constants for RV64I,
making use of the RISCVMatInt::generateInstSeq helper in order to share logic
for immediate materialisation with the MC layer (where it's used for the li
pseudoinstruction).
test/CodeGen/RISCV/imm.ll is updated to test RV64, and gains new 64-bit
constant tests. It would be preferable if anyext constant returns were sign
rather than zero extended (see PR39092). This patch simply adds an explicit
signext to the returns in imm.ll.
Further optimisations for constant materialisation are possible, most notably
for mask-like values which can be generated my loading -1 and shifting right.
A future patch will standardise on the C++ codepath for immediate selection on
RV32 as well as RV64, and then add further such optimisations to
RISCVMatInt::generateInstSeq in order to benefit both RV32 and RV64 for
codegen and li expansion.
Differential Revision: https://reviews.llvm.org/D52962
llvm-svn: 347042
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduces support for '.refsym' assembler directive.
From GCC docs (for MSP430):
'.refsym' - This directive instructs assembler to add an undefined reference
to the symbol following the directive. No relocation is created for this symbol;
it will exist purely for pulling in object files from archives.
Patch by Kristina Bessonova!
Differential Revision: https://reviews.llvm.org/D54618
llvm-svn: 347041
|
|
|
|
|
|
|
|
| |
Patch by Kristina Bessonova!
Differential Revision: https://reviews.llvm.org/D54582
llvm-svn: 347040
|
|
|
|
| |
llvm-svn: 347039
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: sammccall, ioeric
Reviewed By: sammccall
Subscribers: llvm-commits, mgorny, Eugene.Zelenko, ilya-biryukov, jkorous, arphaman, cfe-commits
Differential Revision: https://reviews.llvm.org/D54269
llvm-svn: 347038
|
|
|
|
|
|
|
|
|
|
|
| |
PR37970 reported non-deterministic debug output, this was caused by
iterating through a set and not a a vector.
bugzilla: https://bugs.llvm.org/show_bug.cgi?id=37970
Differential Revision: https://reviews.llvm.org/D54570
llvm-svn: 347037
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This runs checks over a restricted subset of the TU:
- preprocessor callbacks just receive the truncated PP events that
occur when a preamble is used.
- ASTMatchers run only over the top-level decls in the main-file
This patch just turns on one simple check (bugprone-sizeof-expression)
with no configuration. Configuration is complex enough to warrant a separate patch
This depends on a patch allowing traversal to be restricted to a scope.
Reviewers: hokein
Subscribers: srhines, mgorny, ilya-biryukov, ioeric, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D54204
llvm-svn: 347036
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This should be NFC change.
SplitDebugName recently started to accept the `Output` that
can be used to simplify the logic a bit, also it
seems that code in SplitDebugName that uses
OPT_fdebug_compilation_dir is simply dead.
Differential revision: https://reviews.llvm.org/D54576
llvm-svn: 347035
|
|
|
|
|
|
|
|
| |
ANY_EXTEND_VECTOR_INREG when the input and output types need to be widened to the same width.
If we don't do it here, DAGCombine will just end up creating it from the scalar any_extend+build_vector so might as well save a step.
llvm-svn: 347034
|
|
|
|
|
|
|
|
| |
An attempt to recommit r346584 after failure on OSX build bot.
Fixed cache key computation in ThinLTOCodeGenerator and added
test case
llvm-svn: 347033
|
|
|
|
|
|
|
|
| |
-x86-experimental-vector-widening.
By early promoting the multiply to use an i16 element type we can avoid op legalization emit a second multiply for the 8 upper elements of the v16i8 type we would otherwise get.
llvm-svn: 347032
|
|
|
|
|
|
| |
bits with -x86-experimental-vector-widening-legalization.
llvm-svn: 347031
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Current value using as a trap instruction (0xefefefef) is not a good choice
for MIPS because it's a valid MIPS instruction `swc3 $15,-4113(ra)`. This
patch replaces 0xefefefef by 0x04170001. For all MIPS ISA revisions before
R6, this value is just invalid instruction. Starting from MIPS R6 it's
a valid instruction `sigrie 1` which signals a Reserved Instruction exception.
mips-traps.s test case is added to test trap encoding. Other test cases
are modified to remove redundant checking.
Differential revision: https://reviews.llvm.org/D54154
llvm-svn: 347029
|
|
|
|
|
|
|
|
|
| |
If a block had one of the _term instructions used for gluing
exec modifying instructions to the end of the block,
analyzeBranch would fail, preventing the verifier from catching
a broken successor list.
llvm-svn: 347027
|
|
|
|
|
|
|
|
|
|
| |
When second stage is being cross-compiled for a different platform
we need to build enough of first stage runtimes to get a working
compiler.
Differential Revision: https://reviews.llvm.org/D54463
llvm-svn: 347026
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When using multi-stage builds, we would like support cross-compilation.
Example is 2-stage build when the first stage is compiled for host while
the second stage is compiled for the target.
Normally, the second stage would be also used for compiling runtimes,
but that's not possible when cross-compiling, so we use the first stage
compiler instead. However, we still want to use the second stage paths.
To do so, we set the -resource-dir of the first stage compiler to point
to the resource directory of the second stage.
We also need compiler tools that support the target architecture. These
tools are not guaranteed to be present on the host, but in case of
multi-stage build, we can build these tools in the first stage.
Differential Revision: https://reviews.llvm.org/D54461
llvm-svn: 347025
|
|
|
|
|
|
|
|
|
|
|
| |
When building for default target only, use exact target spelling
when deriving the name for the per-target runtime directory. This
is necessary for AArch32 where the CMake build by default rewrites
the architecture which leads to unexpected results.
Differential Revision: https://reviews.llvm.org/D54612
llvm-svn: 347022
|
|
|
|
|
|
|
|
| |
We need to explicitly specify the architecture version.
Differential Revision: https://reviews.llvm.org/D54613
llvm-svn: 347021
|
|
|
|
| |
llvm-svn: 347020
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a compatible vector conversion instead of ambiguous call error
There are 2 function variations with vector type parameter. When we call them with argument of different vector type we would prefer to
choose the variation with implicit argument conversion of compatible vector type instead of incompatible vector type. For example,
typedef float __v4sf __attribute__((__vector_size__(16)));
void f(vector float);
void f(vector signed int);
int main {
__v4sf a;
f(a);
}
Here, we'd like to choose f(vector float) but not report an ambiguous call error.
Differential revision: https://reviews.llvm.org/D53417
llvm-svn: 347019
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Originally we created our 64-bit UID scheme by using the first byte as
sort of a "tag" to represent what kind of symbol this was, and we
re-used the PDB_SymType enumeration for this. For native pdb support,
this is not really the right abstraction layer, because what we really
want is something that tells us *how* to find the symbol. This means,
specifically, is in the globals stream / public stream / module stream /
TPI stream / etc, and for whichever one it is in, where is it within
that stream?
A good example of why the old namespacing scheme was insufficient is
that it is more or less impossible to create a uid for a field list
member of a class/struction/union/enum that tells you how to locate
the original record.
With this new scheme, the first byte is no longer a PDB_SymType enum
but a new enum created specifically to identify where in the PDB
this record lives. This gives us much better flexibility in
what kinds of symbols the uids can identify.
llvm-svn: 347018
|
|
|
|
|
|
|
|
|
| |
Buildbot http://lab.llvm.org:8011/builders/clang-x64-windows-msvc is failing
because it doesn't like paths in VFS, make them more Windows-friendly.
Follow up to r347009.
llvm-svn: 347016
|
|
|
|
|
|
|
|
| |
shorter than 128 bits with -x86-experimental-vector-widening-legalization."
Apparently I failed to update this after turnign sign extend to any extend.
llvm-svn: 347015
|
|
|
|
|
|
| |
bits with -x86-experimental-vector-widening-legalization.
llvm-svn: 347014
|
|
|
|
| |
llvm-svn: 347013
|