| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 294472
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
[mips] MUL macro variations
Adds support for MUL macro variations.
Patch by: Srdjan Obucina
Reviewers: zoran.jovanovic, vkalintiris, dsanders, sdardis, obucina, seanbruno
Differential Revision: https://reviews.llvm.org/D16807
llvm-svn: 294471
|
| |
|
|
| |
llvm-svn: 294470
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
LVI is now depth first, which is optimal for iteration strategy in
terms of work per call. However, the way the results get cached means
it can still go very badly N^2 or worse right now. The overdefined
cache is per-block, because LVI wants to try to get different results
for the same name in different blocks (IE solve the problem
PredicateInfo solves). This means even if we discover a value is
overdefined after going very deep, it doesn't cache this information,
causing it to end up trying to rediscover it again and again. The
same is true for values along the way. In practice, overdefined
anywhere should mean overdefined everywhere (this is how, for example,
SCCP works).
Until we get around to reworking the overdefined cache, we need to
limit the worklist size we process. Note that permanently reverting
the DFS strategy exploration seems the wrong strategy (temporarily
seems fine if we really want). BFS is clearly the wrong approach, it
just gets luckier on some testcases. It's also very hard to design
an effective throttle for BFS. For DFS, the throttle is directly related
to the depth of the CFG. So really deep CFGs will get cutoff, smaller
ones will not. As the CFG simplifies, you get better results.
In BFS, the limit is it's related to the fan-out times average block size,
which is harder to reason about or make good choices for.
Bug being filed about the overdefined cache, but it will require major
surgery to fix it (plumbing predicateinfo through CVP or LVI).
Note: I did not make this number configurable because i'm not sure
anyone really needs to tweak this knob. We run CVP 3 times. On the
testcases i have the slow ones happen in the middle, where CVP is
doing cleanup work other things are effective at. Over the course of
3 runs, we don't see to have any real loss of performance.
I haven't gotten a minimized testcase yet, but just imagine in your
head a testcase where, going *up* the CFG, you have branches, one of
which leads 50000 blocks deep, and the other, to something where the
answer is overdefined immediately. BFS would discover the overdefined
faster than DFS, but do more work to do so. In practice, the right
answer is "once DFS discovers overdefined for a value, stop trying to
get more info about that value" (and so, DFS would normally cache the
overdefined results for every value it passed through in those 50k
blocks, and never do that work again. But it don't, because of the
naming problem)
Reviewers: chandlerc, djasper
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29715
llvm-svn: 294463
|
| |
|
|
|
|
|
|
| |
Some targets don't support uint64_t options. Change type to unsigned.
Differential Revision: https://reviews.llvm.org/D28909
llvm-svn: 294461
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixed test.
Summary:
Enables source location in diagnostic messages from the backend. This
is after parsing, during finalization. This requires the SourceMgr, the
inline assembly string buffer, and DiagInfo to still be alive after
EmitInlineAsm returns.
This patch creates a single SourceMgr for inline assembly inside the
AsmPrinter. MCContext gets a pointer to this SourceMgr. Using one
SourceMgr per call to EmitInlineAsm would make it difficult for
MCContext to figure out in which SourceMgr the SMLoc is located, while a
single SourceMgr can figure it out if it has multiple buffers.
The Str argument to EmitInlineAsm is copied into a buffer and owned by
the inline asm SourceMgr. This ensures that DiagHandlers won't print
garbage. (Clang emits a "note: instantiated into assembly here", which
refers to this string.)
The AsmParser gets destroyed before finalization, which means that the
DiagHandlers the AsmParser installs into the SourceMgr will be stale.
Restore the saved DiagHandlers.
Since now we're using just one SourceMgr for multiple inline asm
strings, we need to tell the AsmParser which buffer it needs to parse
currently. Hand a buffer id -- returned from SourceMgr::
AddNewSourceBuffer -- to the AsmParser.
Reviewers: rnk, grosbach, compnerd, rengolin, rovka, anemet
Reviewed By: rnk
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29441
llvm-svn: 294458
|
| |
|
|
|
|
| |
Run clang-format and standardized variable names between functions.
llvm-svn: 294456
|
| |
|
|
|
|
| |
lines
llvm-svn: 294454
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D28909
llvm-svn: 294453
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D28909
llvm-svn: 294452
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D28760#fb670e28
llvm-svn: 294449
|
| |
|
|
|
|
| |
This reverts commit r294433 because it seems it broke the buildbots.
llvm-svn: 294448
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
It caused undefined behavior in VarLoc. As far as I investigated,
- VarLoc::VarLoc() treats negative offset value as InvalidKind.
Consider the case that (int64_t)MI.getOperand(1).getImm() is negative and whether it satisfies ((uint64_t)Offset < (1ULL << 32)).
- Comparison operators in VarLoc behave undefined since VarLoc::Loc.Hash is uninitialized in case of InvalidKind.
I guess Offset (in VarLoc) could be made aware of signed, but I am not sure.
So I have reverted it for now.
llvm-svn: 294447
|
| |
|
|
| |
llvm-svn: 294445
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Add a register bank for floating point values and select simple instructions
using them (add, copies from GPR).
This assumes that the hardware can cope with a single precision add (VADDS)
instruction, so the legalizer will treat G_FADD as legal and the instruction
selector will refuse to select if the hardware doesn't support it. In the future
we'll want to be more careful about this, and legalize to libcalls if we have to
use soft float.
llvm-svn: 294442
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D29633
llvm-svn: 294441
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D29318
llvm-svn: 294440
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch checks the number of operands in the resulting
instruction instead of just the alias, then skips over
tied operands when generating the printing method.
This allows us to generate the preferred assembly syntax
for the AArch64 'ins' instruction, which should always be
displayed as 'mov' according to the ARMARM.
Several unit tests have changed as a result, but only to
reflect the preferred disassembly.
Some other InstAlias patterns (movk/bic/orr) needed a
slight adjustment to stop them becoming the default
and breaking other unit tests.
Patch by Graham Hunter.
Differential Revision: https://reviews.llvm.org/D29219
llvm-svn: 294437
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Enables source location in diagnostic messages from the backend. This
is after parsing, during finalization. This requires the SourceMgr, the
inline assembly string buffer, and DiagInfo to still be alive after
EmitInlineAsm returns.
This patch creates a single SourceMgr for inline assembly inside the
AsmPrinter. MCContext gets a pointer to this SourceMgr. Using one
SourceMgr per call to EmitInlineAsm would make it difficult for
MCContext to figure out in which SourceMgr the SMLoc is located, while a
single SourceMgr can figure it out if it has multiple buffers.
The Str argument to EmitInlineAsm is copied into a buffer and owned by
the inline asm SourceMgr. This ensures that DiagHandlers won't print
garbage. (Clang emits a "note: instantiated into assembly here", which
refers to this string.)
The AsmParser gets destroyed before finalization, which means that the
DiagHandlers the AsmParser installs into the SourceMgr will be stale.
Restore the saved DiagHandlers.
Since now we're using just one SourceMgr for multiple inline asm
strings, we need to tell the AsmParser which buffer it needs to parse
currently. Hand a buffer id -- returned from SourceMgr::
AddNewSourceBuffer -- to the AsmParser.
Reviewers: rnk, grosbach, compnerd, rengolin, rovka, anemet
Reviewed By: rnk
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29441
llvm-svn: 294433
|
| |
|
|
|
|
|
| |
A previous change seems to have remove #includes from header files. This
fixes the build.
llvm-svn: 294427
|
| |
|
|
|
|
|
| |
It doesn't make any sense to pass in to what is supposed to be parsing
the call, and this can be inferred from the pointer output.
llvm-svn: 294412
|
| |
|
|
| |
llvm-svn: 294410
|
| |
|
|
| |
llvm-svn: 294408
|
| |
|
|
|
|
| |
the feature flag is set.
llvm-svn: 294407
|
| |
|
|
|
|
|
|
| |
we have no support for codegening vmfunc instructions today.
If that support ever gets added, the full feature flag support should come along with it.
llvm-svn: 294406
|
| |
|
|
|
|
|
|
| |
instruction with no plans to release products with it.
Intel's documentation for the deprecation https://software.intel.com/en-us/blogs/2016/09/12/deprecate-pcommit-instruction
llvm-svn: 294405
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The Mips target is the only user of mnemonicIsValid. This patch
moves this method from AsmMatcherEmitter.cpp to MipsAsmParser.cpp,
getting rid of the method in all other targets where it generated
warnings about an unused function.
Patch by Gonsolo.
Reviewers: craig.topper
Reviewed By: craig.topper
Subscribers: sdardis
Differential Revision: https://reviews.llvm.org/D28748
llvm-svn: 294400
|
| |
|
|
|
|
| |
This reverts commit r294398, it seems to be failing on the bots.
llvm-svn: 294399
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
After the DFS order change for LVI, i have a few testcases that now
take forever.
The TL;DR - This is mainly due to the overdefined cache, but that
requires predicateinfo to fix[1]
In order to maximize reuse of the LVI cache for now, change the order
we iterate in.
This reduces my testcase from 5 minutes to 4 seconds.
I have verified cases like gmic do not get slower.
I am playing with whether the order should be postorder or idf.
[1] In practice, overdefined anywhere should be overdefined
everywhere, so this cache should be global. That also fixes this bug.
The problem, however, is that LVI relies on this cache being filled in
per-block because it wants different values in different blocks due to
precisely the naming issue that predicateinfo fixes. With
predicateinfo, making the cache global works fine on individual
passes, and also resolves this issue.
Reviewers: davide, sanjoy, chandlerc
Subscribers: llvm-commits, djasper
Differential Revision: https://reviews.llvm.org/D29679
llvm-svn: 294398
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: As per title.
Reviewers: mkuper, spatel, bkramer, RKSimon, zvi
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29528
llvm-svn: 294394
|
| |
|
|
|
|
|
|
|
|
| |
We should always use unsigned long long to ensure 64 bits. On Windows, unsigned
long is 4 bytes. This was the reason why value-profile-cmp4.test was failing on
Windows.
Differential Revision: https://reviews.llvm.org/D29617
llvm-svn: 294390
|
| |
|
|
|
|
|
|
|
|
| |
Update cmake to use a custom target TestBinaries instead of a list of targets.
This simplifies cmake, and fix some errors. This way, we don't have to propagate
the values into parents directories. We only need to use add_dependencies.
Differential Revision: https://reviews.llvm.org/D29593
llvm-svn: 294389
|
| |
|
|
|
|
|
|
|
|
|
| |
For Windows, sanitizers work with Handles, not with posix file descriptors,
because they use the windows-specific API. So we need to convert the fds to
handles before passing them to the sanitizer library.
After this change, close_fd_mask is fixed for Windows (this fix some tests too).
Differential Revision: https://reviews.llvm.org/D29548
llvm-svn: 294388
|
| |
|
|
|
|
|
|
|
| |
On Windows, executables with the word "uninst" included in their names are
associated with administrator privileges.
Differential Revision: https://reviews.llvm.org/D29549
llvm-svn: 294387
|
| |
|
|
| |
llvm-svn: 294386
|
| |
|
|
|
|
|
|
| |
Use env to set environment variables, so it works on Windows and Linux.
Differential Revision: https://reviews.llvm.org/D29537
llvm-svn: 294385
|
| |
|
|
|
|
|
|
|
| |
Add the option "-n", so we don't add a new line character at the end of the file
when using echo. (on Windows this means 2 characters).
Differential Revision: https://reviews.llvm.org/D29536
llvm-svn: 294384
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D29535
llvm-svn: 294383
|
| |
|
|
|
|
|
|
| |
We can not use the wildcard ? on Windows.
Differential Revision: https://reviews.llvm.org/D29534
llvm-svn: 294382
|
| |
|
|
|
|
|
|
| |
Use env to set environment variables, so it works on Linux and Windows.
Differential Revision: https://reviews.llvm.org/D29533
llvm-svn: 294381
|
| |
|
|
|
|
|
|
|
|
| |
This configuration is necessary, and is included in all tests suites.
We need to execute: `config.test_format = lit.formats.ShTest(False)`
Otherwise, lit will try to use bash, which generates many problems.
Differential Revision: https://reviews.llvm.org/D29529
llvm-svn: 294380
|
| |
|
|
|
|
|
|
|
|
| |
Environment variables are handled differently on Windows. In this case it is not
necessary to use environment variables. So, I simplify the test to work on
Windows.
Differential Revision: https://reviews.llvm.org/D29532
llvm-svn: 294379
|
| |
|
|
|
|
|
|
|
|
| |
We should ensure the size of the variable `a` is 8 bytes. Otherwise, this
generates a stack buffer overflow inside the memcpy call in 32 bits machines.
(We write more bytes than the size of a, when it is 4 bytes)
Differential Revision: https://reviews.llvm.org/D29602
llvm-svn: 294378
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D29531
llvm-svn: 294377
|
| |
|
|
|
|
|
|
|
| |
In this diff, I add stubs for shared memory on Windows. Now we can compile and
use libFuzzer without support for shared memory.
Differential Revision: https://reviews.llvm.org/D29544
llvm-svn: 294376
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently IRCE relies on the loops it transforms to be (semantically) of
the form:
for (i = START; i < END; i++)
...
or
for (i = START; i > END; i--)
...
However, we were not verifying the presence of the START < END entry
check (i.e. check before the first iteration). We were only verifying
that the backedge was guarded by (i + 1) < END.
Usually this would work "fine" since (especially in Java) most loops do
actually have the START < END check, but of course that is not
guaranteed.
llvm-svn: 294375
|
| |
|
|
|
|
| |
minor fixes (NFC).
llvm-svn: 294369
|
| |
|
|
|
|
| |
This is preparation to reduce MC headers dependencies.
llvm-svn: 294368
|
| |
|
|
|
|
| |
std::random_shuffle is being deprecated in C++17. Also simplify fuzzer::Random. NFC
llvm-svn: 294366
|
| |
|
|
|
|
| |
the name.
llvm-svn: 294364
|