| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 295875
|
|
|
|
| |
llvm-svn: 295874
|
|
|
|
| |
llvm-svn: 295873
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: We implement structured exception handling (SEH) by generating filter functions for functions that use exceptions. Currently, we use associative comdats to ensure that the filter functions are preserved if and only if the functions we generated them for are preserved. This can lead to problems when generating COFF objects - LLVM may decide to inline a function that uses SEH and remove its body, at which point we will end up with a comdat that COFF cannot represent. To avoid running into that situation, this change makes us not use associative comdats for SEH filter functions. We can still get the benefits we used the associative comdats for: we will always preserve filter functions we use, and dead stripping can eliminate the ones we don't use.
Reviewers: rnk, pcc, ruiu
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D30117
llvm-svn: 295872
|
|
|
|
|
|
| |
This reverts commit r295867.
llvm-svn: 295871
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Meta: The ultimate goal is to teach ExtParameterInfo about
pass_object_size attributes. This is necessary for that, since our
ExtParameterInfo is a bit buggy in C++. I plan to actually make use of
this Prefix/Suffix info in the near future, but I like small
single-purpose changes. Especially when those changes are hard to
actually test...
At the moment, some of our C++-specific CodeGen pretends that ABIs can
only add arguments to the beginning of a function call. This isn't quite
correct: args can be appended to the end, as well. It hasn't mattered
much until now, since we seem to only use this "number of arguments
added" data when calculating the ExtParameterInfo to use when making a
CGFunctionInfo. Said ExtParameterInfo is currently only used for
ParameterABIs (Swift) and ns_consumed (ObjC).
So, this patch allows ABIs to indicate whether args they added were at
the beginning or end of an argument list. We can use this information to
emit ExtParameterInfos more correctly, though like said, that bit is
coming soon.
No tests since this is theoretically a nop.
llvm-svn: 295870
|
|
|
|
| |
llvm-svn: 295869
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
If the same value is used several times as an extra value, SLP
vectorizer takes it into account only once instead of actual number of
using.
For example:
```
int val = 1;
for (int y = 0; y < 8; y++) {
for (int x = 0; x < 8; x++) {
val = val + input[y * 8 + x] + 3;
}
}
```
We have 2 extra rguments: `1` - initial value of horizontal reduction
and `3`, which is added 8*8 times to the reduction. Before the patch we
added `1` to the reduction value and added once `3`, though it must be
added 64 times.
Reviewers: mkuper, mzolotukhin
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D30262
llvm-svn: 295868
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D30232
llvm-svn: 295867
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A 'decltype(auto)' parameter can match any other kind of non-type template
parameter, so should be usable in place of any other parameter in a template
template argument. The standard is sadly extremely unclear on how this is
supposed to work, but this seems like the obviously-correct result.
It's less clear whether an 'auto' parameter should be able to match
'decltype(auto)', since the former cannot be used if the latter turns out to be
used for a reference type, but if we disallow that then consistency suggests we
should also disallow 'auto' matching 'T' for the same reason, defeating
intended use cases of the feature.
llvm-svn: 295866
|
|
|
|
|
|
|
| |
This should make gcc happy and still produce a clang warning if we add
another value to the enum.
llvm-svn: 295865
|
|
|
|
| |
llvm-svn: 295864
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Extend AArch64RedundantCopyElimination to catch cases where the register
that is known to be zero is COPY'd in the predecessor block. Before
this change, this pass would catch cases like:
CBZW %W0, <BB#1>
BB#1:
%W0 = COPY %WZR // removed
After this change, cases like the one below are also caught:
%W0 = COPY %W1
CBZW %W1, <BB#1>
BB#1:
%W0 = COPY %WZR // removed
This change results in a 4% increase in static copies removed by this
pass when compiling the llvm test-suite. It also fixes regressions
caused by doing post-RA copy propagation (a separate change to be put up
for review shortly).
Reviewers: junbuml, mcrosier, t.p.northover, qcolombet, MatzeB
Subscribers: aemerson, rengolin, llvm-commits
Differential Revision: https://reviews.llvm.org/D30113
llvm-svn: 295863
|
|
|
|
| |
llvm-svn: 295862
|
|
|
|
|
|
|
| |
Instead, just be conservative as these are unfrequent enough. Thanks
to Peter Collingbourne for the discussion about this on IRC.
llvm-svn: 295861
|
|
|
|
|
|
|
| |
Also, update the version number to 0x1, which is what engines are now
expecting.
llvm-svn: 295860
|
|
|
|
|
|
|
| |
llc mir output goes to stdout nowadays, so the 2>&1 is not necessary
anymore for most tests.
llvm-svn: 295859
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Prevent memory objects of different address spaces to be part of
the same load/store groups when analysing interleaved accesses.
This is fixing pr31900.
Reviewers: HaoLiu, mssimpso, mkuper
Reviewed By: mssimpso, mkuper
Subscribers: llvm-commits, efriedma, mzolotukhin
Differential Revision: https://reviews.llvm.org/D29717
This reverts r295042 (re-applies r295038) with an additional fix for the
buildbot problem.
llvm-svn: 295858
|
|
|
|
|
|
|
|
|
|
| |
LLVM CodeGen emits references to external symbols that are never declared in
LLVM IR level, so they have no declared signature. However, WebAssembly requires
all functions be declared with signatures. This patch adds a table for providing
signatures for known runtime libcalls that will be used in subsequent patches to
emit declarations for such functions.
llvm-svn: 295857
|
|
|
|
| |
llvm-svn: 295856
|
|
|
|
| |
llvm-svn: 295855
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The function for distinguishing local and remote files added in r295768
unconditionally uses linux/magic.h header to provide necessary
filesystem magic numbers. However, in kernel headers predating 2.6.18
the magic numbers are spread throughout multiple include files.
Furthermore, LLVM did not require kernel headers being installed so far.
To increase the portability across different versions of Linux kernel
and different Linux systems, add CMake header checks for linux/magic.h
and -- if it is missing -- the linux/nfs_fs.h and linux/smb.h headers
which contained the numbers previously.
Furthermore, since the numbers are static and the feature does not seem
critical enough to make LLVM require kernel headers at all, add fallback
constants for the case when none of the necessary headers is available.
Differential Revision: https://reviews.llvm.org/D30261
llvm-svn: 295854
|
|
|
|
| |
llvm-svn: 295853
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: The CallTargetProfile should be added to FProfile to be consistent with other profile readers.
Reviewers: dnovillo, davidxl
Reviewed By: davidxl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D30233
llvm-svn: 295852
|
|
|
|
| |
llvm-svn: 295850
|
|
|
|
|
|
|
|
|
|
|
| |
r295336 causes a bootstrapped clang to fail for many compilations on
powerpc BE. See
http://lab.llvm.org:8011/builders/clang-ppc64be-linux-multistage/builds/2315
for example.
Reverting as per the developer's request.
llvm-svn: 295849
|
|
|
|
|
|
|
|
| |
into masks.
Minor optimization, don't create temporary mask APInts that are just going to be OR'd into the accumulate masks - insert directly instead.
llvm-svn: 295848
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These tests were not included in the main DeLICM commit. These check the
cases where zone analysis cannot be successful because of assumption
violations.
We use the LLVM optimization remark infrastructure as it seems to be the
best fit for this kind of messages. I tried to make use if the
OptimizationRemarkEmitter. However, it would insert additional function
passes into the pass manager to get the hotness information. The pass
manager would insert them between the flatten pass and delicm, causing
the ScopInfo with the flattened schedule being thrown away.
Differential Revision: https://reviews.llvm.org/D30253
llvm-svn: 295846
|
|
|
|
|
|
| |
separately. NFCI.
llvm-svn: 295845
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D30236
llvm-svn: 295843
|
|
|
|
|
|
|
| |
is_local can't pass on some our buildbots as some of our buildbots use network
shares for building and testing LLVM.
llvm-svn: 295840
|
|
|
|
|
|
| |
The following fully-covered switch either sets value to External or exits the function.
llvm-svn: 295839
|
|
|
|
|
|
|
| |
Correct a comment that claimed that a store after load was detected
when the code checks a load after a store.
llvm-svn: 295835
|
|
|
|
|
|
|
| |
test corrections.
NB: several old tests have been corrected because they violated constant bus limitations
llvm-svn: 295834
|
|
|
|
|
|
|
| |
This is to distinguish the cases that analysis has failed from the case
where not transformation was performed.
llvm-svn: 295833
|
|
|
|
|
|
|
|
| |
There is no template specialization for cl::parser<unsigned long> such
that parsing an cl::opt<unsigned long> command line argument will fail.
Use opt<int> instead which has an associated parser.
llvm-svn: 295832
|
|
|
|
|
|
| |
checking
llvm-svn: 295830
|
|
|
|
| |
llvm-svn: 295829
|
|
|
|
|
|
| |
field from ODRDeclVisitor
llvm-svn: 295828
|
|
|
|
| |
llvm-svn: 295827
|
|
|
|
| |
llvm-svn: 295826
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Initial implementation for X86InstructionSelector. Handle selection COPY and G_ADD/G_SUB gpr, gpr .
Reviewers: qcolombet, rovka, zvi, ab
Reviewed By: rovka
Subscribers: mgorny, dberris, kristof.beyls, llvm-commits
Differential Revision: https://reviews.llvm.org/D29816
llvm-svn: 295824
|
|
|
|
| |
llvm-svn: 295823
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The main difference here is that in the WINLOG macros you can specify
log categories per call, whereas here you have to go the usual lldb
route of getting a Log* variable first. While this means you have to
write at least two statements, it usually means that each statement will
fit on a single line, whereas fitting the WINLOG invocation on a single
line was almost impossible. So the total size of code does not increase
even in functions with a single log statement, and functions with more
logging get shorter.
The downside here is reduced flexibility in specifying the log
categories, which a couple of functions used quite heavily (e.g.
RefreshStateAfterStop). For these I chose a single category used most
prominently and put everything into that, although a solution with
multiple log variables is definitely possible.
Reviewers: zturner, amccarth
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D30172
llvm-svn: 295822
|
|
|
|
| |
llvm-svn: 295821
|
|
|
|
|
|
| |
Found by MSAN.
llvm-svn: 295820
|
|
|
|
| |
llvm-svn: 295819
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Quitting inside a process sentinel is not allowed, but the sentinel invokes
completion, where the user is free to hit C-g. By wrapping the call in
with-local-quit, the process sentinel invocation can finish without triggering
an error
2. Invoke completing-read instead of ido-completing-read, since this may
interfere with user customizations to completing-read-function. The user should
use something like ido-ubiquitous if ido completion is wanted
3. Compare the string returned from completion with string=, since it may be a
copy of the original string in the collection
Patch by Torsten Marek.
llvm-svn: 295818
|
|
|
|
|
|
|
| |
* Added comment.
* Pass std::string copy instead using move semantic.
llvm-svn: 295817
|
|
|
|
|
|
|
|
|
|
|
|
| |
The pass tries to fix a spill of LR that turns out to be unnecessary.
So it removes the tPOP but forgets to remove tPUSH.
This causes the stack be misaligned upon returning the function.
Thus, remove the tPUSH as well in this case.
Differential Revision: https://reviews.llvm.org/D30207
llvm-svn: 295816
|