| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 280585
|
|
|
|
|
|
|
|
|
| |
readlane/writelane do not support using m0 as the output/input.
Constrain the register class of spill vregs to try to avoid this,
but also handle spilling of the physreg when necessary by inserting
an additional copy to a normal SGPR.
llvm-svn: 280584
|
|
|
|
| |
llvm-svn: 280583
|
|
|
|
| |
llvm-svn: 280581
|
|
|
|
| |
llvm-svn: 280580
|
|
|
|
| |
llvm-svn: 280579
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some Windows SDK classes, for example
Windows::Storage::Streams::IBufferByteAccess, use the ATL way of spelling
attributes:
[uuid("....")] class IBufferByteAccess {};
To be able to use __uuidof() to grab the uuid off these types, clang needs to
support uuid as a Microsoft attribute. There was already code to skip Microsoft
attributes, extend that to look for uuid and parse it. Use the new "Microsoft"
attribute type added in r280575 (and r280574, r280576) for this.
Final part of https://reviews.llvm.org/D23895
llvm-svn: 280578
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The test it added doesn't pass:
http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/15318/steps/ninja%20check%201/logs/FAIL%3A%20LLVM%3A%3Apdbdump-yaml-types.test
Command Output (stdout):
--
$ "D:/buildslave/clang-x64-ninja-win7/stage1/./bin\llvm-pdbdump.EXE" "pdb2yaml" "-tpi-stream" "D:\buildslave\clang-x64-ninja-win7\llvm\test\DebugInfo\PDB/Inputs/empty.pdb"
$ "D:/buildslave/clang-x64-ninja-win7/stage1/./bin\FileCheck.EXE" "-check-prefix=YAML" "D:\buildslave\clang-x64-ninja-win7\llvm\test\DebugInfo\PDB\pdbdump-yaml-types.test"
# command stderr:
D:\buildslave\clang-x64-ninja-win7\llvm\test\DebugInfo\PDB\pdbdump-yaml-types.test:36:7: error: expected string not found in input
YAML: Name: apartment
^
<stdin>:153:10: note: scanning from here
Value: 161
^
llvm-svn: 280577
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There was already a function that moved attributes off the declspec into
an attribute list for attributes applying to the type, teach that function to
also move Microsoft attributes around and rename it to match its new broader
role.
Nothing uses Microsoft attributes yet, so no behavior change.
Part of https://reviews.llvm.org/D23895
llvm-svn: 280576
|
|
|
|
|
|
|
|
| |
This is for attributes in []-delimited lists preceding a class, like e.g.
`[uuid("...")] class Foo {};` Not used by anything yet, so no behavior change.
Part of https://reviews.llvm.org/D23895
llvm-svn: 280575
|
|
|
|
|
|
|
|
| |
into ParseDeclOrFunctionDefInternal() (which is called by
MaybeParseMicrosoftAttributes()), so that the attributes can be stored in
the DeclSpec. No behavior change yet, part of https://reviews.llvm.org/D23895
llvm-svn: 280574
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The only intrusive thing about SparseBitVector's usage of ilist<> was
that new was usually called externally. There were no custom traits.
It seems like the reason to switch to ilist in r41855 was to avoid
pointer invalidation, but std::list<> has that feature too. Maybe
std::list<>::emplace makes this a little more obvious than it was then.
Switch over to std::list<> and simplify the code.
llvm-svn: 280573
|
|
|
|
|
|
|
|
|
| |
The comment starting with "ParseDeclarationOrFunctionDefinition -" is above
a function called ParseDeclOrFunctionDefInternal. Fix the comment by not
mentioning a function name, like the style guide requests nowadays. No behavior
change.
llvm-svn: 280572
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PowerPC assembly code in the wild, so it seems, has things like this:
bc+ 12, 28, .L9
This is a bit odd because the '+' here becomes part of the BO field, and the BO
field is otherwise the first operand. Nevertheless, the ISA specification does
clearly say that the +- hint syntax applies to all conditional-branch mnemonics
(that test either CTR or a condition register, although not the forms which
check both), both basic and extended, so this is supposed to be valid.
This introduces some asm-parser-only definitions which take only the upper
three bits from the specified BO value, and the lower two bits are implied by
the +- suffix (via some associated aliases).
Fixes PR23646.
llvm-svn: 280571
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Inheriting from std::iterator uses more boiler-plate than manual
typedefs. Avoid that in both ilist_iterator and
MachineInstrBundleIterator.
This has the side effect of removing ilist_iterator from certain ADL
lookups in namespace std; calls to std::next need to be qualified by
"std::" that didn't have to before. The one case of this in-tree was
operating on a temporary, so I used the more compact operator++.
llvm-svn: 280570
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Split out iplist_impl from iplist, and change SymbolTableList to inherit
directly from iplist_impl. This makes it more straightforward to add
new template paramaters to iplist [*]:
- iplist_impl takes a "base" list that provides the intrusive
functionality (usually simple_ilist<T>) and a traits class.
- iplist no longer takes a "Traits" template parameter. It only takes
the value_type, T, and instantiates iplist_impl with simple_ilist<T>
and ilist_traits<T>.
- SymbolTableList now inherits from iplist_impl, instead of iplist.
Note for out-of-tree code: if you have an iplist whose second template
parameter was *not* the default (i.e., not ilist_traits<YourT>), you
have three options:
- Stop using a custom traits class, and instead specialize
ilist_traits<YourT>. This is the usual thing to do.
- Specialize iplist<YourT> to pass your custom traits class into
iplist_impl.
- Create your own trivial list type that passes your custom traits class
into iplist_impl (see SymbolTableList<> for an example).
[*]: The eventual goal is to start tracking a sentinel bit on the
MachineInstr list even when LLVM_ENABLE_ABI_BREAKING_CHECKS is off,
which will enable MachineBasicBlock::reverse_iterator to have normal
list invalidation semantics that matching the new
iplist<>::reverse_iterator from r280032.
llvm-svn: 280569
|
|
|
|
|
|
| |
Add -mtriple=x86_64-unknown-linux-gnu for the test and move it to CodeGen/X86.
llvm-svn: 280568
|
|
|
|
|
|
| |
And use other typedefs so that the next rename has a smaller diff.
llvm-svn: 280567
|
|
|
|
|
|
|
| |
Adopt r280128 in lld, specializing ilist_alloc_traits rather than
reinventing the wheel.
llvm-svn: 280566
|
|
|
|
|
|
|
|
|
|
|
|
| |
Delete the dead code for Write(ilist_iterator) in the IR Verifier,
inline report(ilist_iterator) at its call sites in the MachineVerifier,
and use simple_ilist<>::iterator in SymbolTableListTraits.
The only remaining reference to ilist_iterator outside of the ilist
implementation is from MachineInstrBundleIterator. I'll get rid of that
in a follow-up.
llvm-svn: 280565
|
|
|
|
|
|
|
|
| |
This test was using the wrong type, and so not actually testing much.
ilist_iterator constructors weren't going through ilist_node_access, so
they didn't actually work with private inheritance.
llvm-svn: 280564
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Simple utility methods will prevent users from making mistakes when
converting element counts to byte counts.
Reviewers: jlebar
Subscribers: jprice, parallel_libs-commits
Differential Revision: https://reviews.llvm.org/D24197
llvm-svn: 280563
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have invariants we like to guarantee for the
`ImplicitConversionKind`s in a `StandardConversionSequence`. These
weren't being upheld in code that r280553 touched, so Richard suggested
that we should fix that. See D24113.
I'm not entirely sure how to go about testing this, so no test case is
included. Suggestions welcome.
llvm-svn: 280562
|
|
|
|
|
|
| |
__attribute__((require_constant_initialization)), and apply it to memory_resource
llvm-svn: 280561
|
|
|
|
|
|
|
|
| |
These few book-III instructions are used by the Linux kernel.
Partially fixes PR24796.
llvm-svn: 280560
|
|
|
|
|
|
|
|
|
| |
dcbf has an optional hint-like field, add support for the extended form and the
associated mnemonics (dcbfl and dcbflp).
Partially fixes PR24796.
llvm-svn: 280559
|
|
|
|
|
|
|
|
|
| |
Without reductions we do not need a flat union_map schedule describing
the computation we want to perform, but can work purely on the schedule
tree. This reduces the dependence computation and scheduling time from 33ms
to 25ms. Another 30% reduction.
llvm-svn: 280558
|
|
|
|
|
|
|
|
|
|
|
|
| |
In case we do not compute reduction dependences or dependences that are more
fine-grained than statement level dependences, we can avoid the corresponding
part of the dependence analysis all together. For the 3mm benchmark, this
reduces scheduling + dependence analysis time from 62ms to 33ms for a no-asserts
build. The majority of the compile time is anyhow spent in the LLVM backends,
when doing code generation. Nevertheless, there is no need to waste compile time
either.
llvm-svn: 280557
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
block.
Clang tests for verifying the following syntaxes:
1. 0xNN and NNh are accepted as valid hexadecimal numbers, but 0xNNh is not.
0xNN and NNh may come with optional U or L suffix.
2. NNb is accepted as a valid binary (base-2) number, but 0bNN is not.
NNb may come with optional U or L suffix.
Differential Revision: https://reviews.llvm.org/D22112
llvm-svn: 280556
|
|
|
|
|
|
|
|
|
|
|
| |
1. 0xNN and NNh are accepted as valid hexadecimal numbers, but 0xNNh is not.
0xNN and NNh may come with optional U or L suffix.
2. NNb is accepted as a valid binary (base-2) number, but 0bNN is not.
NNb may come with optional U or L suffix.
Differential Revision: https://reviews.llvm.org/D22112
llvm-svn: 280555
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We replace the options
-polly-code-generator=none
=isl
with the options
-polly-code-generation=none
=ast
=full
This allows us to measure the overhead of Polly itself, versus the compile
time increases due to us generating more IR and consequently the LLVM backends
spending more time on this IR.
We also use this opportunity to rename the option. The original name was
introduced at a point where we still had two code generators. CLooG and the
isl AST generator. Since we only have one AST generator left, there is no need
to distinguish between 'isl' and something else. However, being able to disable
code generation all together has been shown useful for debugging. Hence, we
rename and extend this option to make it a good fit for its new use case.
llvm-svn: 280554
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch allows us to perform incompatible pointer conversions when
resolving overloads in C. So, the following code will no longer fail to
compile (though it will still emit warnings, assuming the user hasn't
opted out of them):
```
void foo(char *) __attribute__((overloadable));
void foo(int) __attribute__((overloadable));
void callFoo() {
unsigned char bar[128];
foo(bar); // selects the char* overload.
}
```
These conversions are ranked below all others, so:
A. Any other viable conversion will win out
B. If we had another incompatible pointer conversion in the example
above (e.g. `void foo(int *)`), we would complain about
an ambiguity.
Differential Revision: https://reviews.llvm.org/D24113
llvm-svn: 280553
|
|
|
|
|
|
|
|
| |
Author: Krzysztof Parzyszek <kparzysz@codeaurora.org>
Differential Revision: https://reviews.llvm.org/D24209
llvm-svn: 280552
|
|
|
|
|
|
|
|
|
|
| |
Summary: VS code creates .vscode folder to keep its stuff that we really don't need in git.
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D24211
llvm-svn: 280551
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is a follow up to r280455, where a check for the process exit code
was introduced. Some ASAN bots throw this error now, but it's impossible
to understand what's wrong with them, and the issue is not reproducible.
Reviewers: vitalybuka
Differential Revision: https://reviews.llvm.org/D24210
llvm-svn: 280550
|
|
|
|
|
|
|
|
|
|
|
| |
Before we were kind of imitating the behavior of a Yaml sequence
by outputting each record one after the other. This makes it a
little cumbersome when we want to go the other direction -- from
Yaml to Pdb. So this treats FieldList records as no different than
any other list of records, by printing them as a Yaml sequence with
the exact same format.
llvm-svn: 280549
|
|
|
|
| |
llvm-svn: 280548
|
|
|
|
|
|
|
|
|
| |
Builtin expect lowering currently ignores select. This patch
fixes the issue
Differential Revision: http://reviews.llvm.org/D24166
llvm-svn: 280547
|
|
|
|
|
|
|
|
|
|
|
| |
The patch adds support for both '-' and '~' unary expressions. Also it
brings support for signed numbers is expressions.
https://llvm.org/bugs/show_bug.cgi?id=30221
Differential revision: https://reviews.llvm.org/D24128
llvm-svn: 280546
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we have an offset into a global, etc. that is accessed relative to the TOC
base pointer, and the offset is larger than the minimum alignment of the global
itself and the TOC base pointer (which is 8-byte aligned), we can still fold
the @toc@ha into the memory access, but we must update the addis instruction's
symbol reference with the offset as the symbol addend. When there is only one
use of the addi to be folded and only one use of the addis that would need its
symbol's offset adjusted, then we can make the adjustment and fold the @toc@l
into the memory access.
llvm-svn: 280545
|
|
|
|
|
|
|
|
|
|
| |
Use std::regex instead of hand written matcher.
Patch based on code and ideas of Rui Ueyama.
Differential revision: https://reviews.llvm.org/D23829
llvm-svn: 280544
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When <bitset> is compiled with warnings enabled, on a platform where
size_t is 4 bytes, it results in errors similar to:
bitset:265:16: error: non-constant-expression cannot be narrowed
from type 'unsigned long long' to '__storage_type' (aka 'unsigned
int') in initializer list [-Wc++11-narrowing]
: __first_{__v, __v >> __bits_per_word}
^~~
bitset:676:52: note: in instantiation of member function
'std::__1::__bitset<2, 53>::__bitset' requested here
bitset(unsigned long long __v) _NOEXCEPT : base(__v) {}
^
Fix these by casting the initializer list elements to __storage_type.
Reviewers: mclow.lists, EricWF
Differential Revision: https://reviews.llvm.org/D23960
llvm-svn: 280543
|
|
|
|
|
|
|
|
|
|
|
|
| |
When affinity isn't supported, __kmp_affinity_compact doesn't exist. The
problem is that in kmp_affinity.h there is a function which uses it without the
proper KMP_AFFINITY_SUPPORTED guard around it. The compiler was smart enough to
ignore it and the function __kmp_affinity_cmp_Address_child_num which relies on
it, but I think it is cleaner to have it under the proper guard. Since the
function is only used in the kmp_affinity.cpp file and there aren't any plans to
have it elsewhere. I have moved it there.
llvm-svn: 280542
|
|
|
|
| |
llvm-svn: 280541
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D24207
llvm-svn: 280540
|
|
|
|
| |
llvm-svn: 280539
|
|
|
|
|
|
|
| |
the __kmp_affinity_determine_capable() functions are highly operating system
specific. This change has the functions use the type they expect explicitly.
llvm-svn: 280538
|
|
|
|
|
|
|
|
|
|
|
| |
Recently, llvm wants to emit calls to these functions, while it didn't
seem to be an issue before. Not sure why. Nor do I know why only these
three are important to disable, out of all of the i128 libcalls.
Nevertheless, many other targets have this snippet of code, so, just
copying it to sparc as well, to unbreak things.
llvm-svn: 280537
|
|
|
|
|
|
|
|
|
|
| |
od is defined by POSIX and exists since version 1 AT&T Unix.
hexdump is not part of any standard as far as I know.
So od is a better choice than hexdump.
Differential Revision: https://reviews.llvm.org/D24205
llvm-svn: 280536
|
|
|
|
|
|
|
|
|
|
| |
have the same number of elements.
Fixes R600 piglit regressions since r280298
Differential Revision: https://reviews.llvm.org/D24174
llvm-svn: 280535
|