| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch introduces two helpers to make it easier to ignore debug
intrinsics:
- Instruction::getNextNonDebugInstruction()
This is just like Instruction::getNextNode(), except that it skips debug
info.
- skipDebugInfo(BasicBlock::iterator)
A free function which advances a BasicBlock iterator past any debug
info. This is a no-op when the iterator already points to a non-debug
instruction.
Part of: llvm.org/PR37728
Related to: https://reviews.llvm.org/D47874
Differential Revision: https://reviews.llvm.org/D48305
llvm-svn: 335083
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The optimizer is getting smarter (eg, D47986) about differentiating shuffles
based on its mask values, so we should make queries on the mask constant
operand generally available to avoid code duplication.
We'll probably use this soon in the vectorizers and instcombine (D48023 and
https://bugs.llvm.org/show_bug.cgi?id=37806).
We might clean up TTI a bit more once all of its current 'SK_*' options are
covered.
Differential Revision: https://reviews.llvm.org/D48236
llvm-svn: 335067
|
|
|
|
|
|
|
|
| |
functionality.""
Fix typo: LLVM_NATIVE_ARCH -> LLVM_EXEGESIS_NATIVE_ARCH.
llvm-svn: 335041
|
|
|
|
|
|
|
|
| |
functionality."
Breaks buildbots.
llvm-svn: 335040
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This is a step towards implementing memory operands and X87.
Reviewers: gchatelet
Subscribers: mgorny, tschuett, llvm-commits
Differential Revision: https://reviews.llvm.org/D48210
llvm-svn: 335038
|
|
|
|
|
|
|
|
|
|
| |
Summary: A recent commit forgot to update the unit tests.
Differential Revision: https://reviews.llvm.org/D48304
Patch by Wouter Van Oortmerssen
llvm-svn: 334999
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Without these, build with `-DSHARED_LIB=ON` fails.
Reviewers: dschuff
Subscribers: mgorny, bollu, tschuett, rkruppe, rogfer01, llvm-commits
Differential Revision: https://reviews.llvm.org/D48300
llvm-svn: 334997
|
|
|
|
|
|
|
|
|
|
|
| |
MergeBlockIntoPredecessor"
This reverts commit f976cf4cca0794267f28b54e468007fd476d37d9.
I am reverting this because it causes break in a few bots and its going
to take me sometime to look at this.
llvm-svn: 334993
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Simplify blockaddress usage before giving up in MergeBlockIntoPredecessor
This is a missing small optimization in MergeBlockIntoPredecessor.
This helps with one simplifycfg test which expects this case to be handled.
Reviewers: davide, spatel, brzycki, asbirlea
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D48284
llvm-svn: 334992
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch introduces a VPInstructionToVPRecipe transformation, which
allows us to generate code for a VPInstruction based VPlan re-using the
existing infrastructure.
Reviewers: dcaballe, hsaito, mssimpso, hfinkel, rengolin, mkuper, javed.absar, sguggill
Reviewed By: dcaballe
Differential Revision: https://reviews.llvm.org/D46827
llvm-svn: 334969
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: dcaballe, hsaito, mkuper, hfinkel
Reviewed By: dcaballe
Differential Revision: https://reviews.llvm.org/D48081
llvm-svn: 334951
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: dcaballe, mkuper, hfinkel, hsaito, mssimpso
Reviewed By: dcaballe
Differential Revision: https://reviews.llvm.org/D48080
llvm-svn: 334933
|
|
|
|
|
|
|
|
| |
changes.
This guards against redundant notifications.
llvm-svn: 334916
|
|
|
|
| |
llvm-svn: 334910
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
DominatorTreeBase::getNode does not modify its parameter and this change
allows callers that only have access to const pointers to use it without
casting.
Reviewers: kuhar, dblaikie, chandlerc
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D48231
llvm-svn: 334892
|
|
|
|
| |
llvm-svn: 334889
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds a simple const_iterator implementation for SmallSet by
delegating to either a SmallVector::const_iterator or
std::set::const_iterator, depending on which storage is used by the
SmallSet.
Reviewers: dblaikie, craig.topper
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D47942
llvm-svn: 334887
|
|
|
|
|
|
|
|
|
| |
Once a symbol has been selected for materialization it can no longer be
overridden. Stripping the weak flag guarantees this (override attempts will
then be treated as duplicate definitions and result in a DuplicateDefinition
error).
llvm-svn: 334771
|
|
|
|
| |
llvm-svn: 334724
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Get rid of OpcodeName.
To remove the opcode name from an old file:
```
cat old_file | sed '/opcode_name.*/d'
```
Reviewers: gchatelet
Subscribers: tschuett, llvm-commits
Differential Revision: https://reviews.llvm.org/D48121
llvm-svn: 334691
|
|
|
|
|
|
|
|
| |
This is failing to compile when LLVM_ENABLE_THREADS is false,
and the fix is not immediately obvious, so reverting while I look
into it.
llvm-svn: 334658
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously ThreadPool could only queue async "jobs", i.e. work
that was done for its side effects and not for its result. It's
useful occasionally to queue async work that returns a value.
From an API perspective, this is very intuitive. The previous
API just returned a shared_future<void>, so all we need to do is
make it return a shared_future<T>, where T is the type of value
that the operation returns.
Making this work required a little magic, but ultimately it's not
too bad. Instead of keeping a shared queue<packaged_task<void()>>
we just keep a shared queue<unique_ptr<TaskBase>>, where TaskBase
is a class with a pure virtual execute() method, then have a
templated derived class that stores a packaged_task<T()>. Everything
else works out pretty cleanly.
Differential Revision: https://reviews.llvm.org/D48115
llvm-svn: 334643
|
|
|
|
|
|
|
|
|
|
| |
Multiplication followed by addition
(https://en.wikipedia.org/wiki/Multiply–accumulate_operation) is a
sufficiently common use-case to warrant a separate helper.
Differential Revision: https://reviews.llvm.org/D48138
llvm-svn: 334635
|
|
|
|
|
|
|
|
|
|
| |
Returning optional is much safer.
The previous API had potential to cause use of undefined variables, if
the value passed by pointer was accidentally read afterwards.
Differential Revision: https://reviews.llvm.org/D48137
llvm-svn: 334634
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Even if we support no-canonical-prefix on
clang-cl(https://reviews.llvm.org/D47480), argv0 becomes absolute path
in clang-cl and that embeds absolute path in /showIncludes.
This patch removes such full path normalization from InitLLVM on
windows, and that removes absolute path from clang-cl output
(obj/stdout/stderr) when debug flag is disabled.
Patch by Takuto Ikuta!
Differential Revision https://reviews.llvm.org/D47578
llvm-svn: 334602
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: courbet
Reviewed By: courbet
Subscribers: tschuett, llvm-commits
Differential Revision: https://reviews.llvm.org/D48125
llvm-svn: 334601
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: courbet
Subscribers: tschuett, llvm-commits
Differential Revision: https://reviews.llvm.org/D48123
llvm-svn: 334599
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Previous design was relying on the 'mutate' keyword and was quite confusing. This version separate mutable from immutable data and makes it clearer what changes and what doesn't.
Reviewers: courbet
Subscribers: tschuett, llvm-commits
Differential Revision: https://reviews.llvm.org/D48020
llvm-svn: 334596
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a VSO has a fallback definition generator attached it will be called during
lookup (and lookupFlags) for any unresolved symbols. The definition generator
can add new definitions to the VSO for any unresolved symbol. This allows VSOs
to generate new definitions on demand.
The immediate use case for this code is supporting VSOs that can import
definitions found via dlsym on demand.
llvm-svn: 334538
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This simplifies some code which had StringRefs to begin with, and
makes other code more complicated which had const char* to begin
with.
In the end, I think this makes for a more idiomatic and platform
agnostic API. Not all platforms launch process with null terminated
c-string arrays for the environment pointer and argv, but the api
was designed that way because it allowed easy pass-through for
posix-based platforms. There's a little additional overhead now
since on posix based platforms we'll be takign StringRefs which
were constructed from null terminated strings and then copying
them to null terminate them again, but from a readability and
usability standpoint of the API user, I think this API signature
is strictly better.
llvm-svn: 334518
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This patch moves linking of libpfm from different places to a single one.
Reviewers: courbet
Subscribers: mgorny, tschuett, llvm-commits
Differential Revision: https://reviews.llvm.org/D48075
llvm-svn: 334499
|
|
|
|
|
|
|
| |
Some out-of-tree targets depend on the enum name SPF_Binary. Keep the name
can avoid unnecessary churn to those targets.
llvm-svn: 334476
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Name table occupies a big chunk of size in current binary format sample profile.
In order to reduce its size, the patch changes the sample writer/reader to
save/restore MD5Hash of names in the name table. Sample annotation phase will
also use MD5Hash of name to query samples accordingly.
Experiment shows compact binary format can reduce the size of sample profile by
2/3 compared with binary format generally.
Differential Revision: https://reviews.llvm.org/D47955
llvm-svn: 334447
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This kind of functionality is useful to other project apart from clang.
LLDB works with version numbers a lot, but it does not have a convenient
abstraction for this. Moving this class to a lower level library allows
it to be freely used within LLDB.
Since this class is used in a lot of places in clang, and it used to be
in the clang namespace, it seemed appropriate to add it to the list of
adopted classes in LLVM.h to avoid prefixing all uses with "llvm::".
Also, I didn't find any tests specific for this class, so I wrote a
couple of quick ones for the more interesting bits of functionality.
Reviewers: zturner, erik.pilkington
Subscribers: mgorny, cfe-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D47887
llvm-svn: 334399
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A recent change https://reviews.llvm.org/D46898 which had no intended
behavior change, actually modified the linker flags used when linking
the dynamic libraries used by the DynamicLibraryTests unit test. This
made the test fail in our testing environment which runs the tests
from an NFS share. Prior to D46898 the two libraries used by the test
were different (because the library name used to be embedded into the
binary), and after the change they became bit-to-bit identical. This
causes dlopen to return the same handle when these two libraries are
loaded from an NFS share, and the test expects two different handles.
This patch reverts the part of D46898 that is responsible for
changing the linker flags.
Differential Revision: https://reviews.llvm.org/D47469
llvm-svn: 334394
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: craig.topper, dblaikie
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D47940
llvm-svn: 334321
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Add `StringRef::rsplit(StringRef Separator)` to achieve the function of getting the tail substring according to the separator. A typical usage is to get `data` in `std::basic_string::data`.
Reviewers: mehdi_amini, zturner, beanz, xbolva00, vsk
Reviewed By: zturner, xbolva00, vsk
Subscribers: vsk, xbolva00, llvm-commits, MTC
Differential Revision: https://reviews.llvm.org/D47406
llvm-svn: 334283
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This breaks the OpenFlags enumeration into two separate
enumerations: OpenFlags and CreationDisposition. The first
controls the behavior of the API depending on whether or not
the target file already exists, and is not a flags-based
enum. The second controls more flags-like values.
This yields a more easy to understand API, while also allowing
flags to be passed to the openForRead api, where most of the
values didn't make sense before. This also makes the apis more
testable as it becomes easy to enumerate all the configurations
which make sense, so I've added many new tests to exercise all
the different values.
llvm-svn: 334221
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: BenchmarkResult IO functions now return an Error or Expected so caller can deal take proper action.
Reviewers: courbet
Subscribers: tschuett, llvm-commits
Differential Revision: https://reviews.llvm.org/D47868
llvm-svn: 334167
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Follow up patch to https://reviews.llvm.org/D47764.
Reviewers: courbet
Subscribers: tschuett, llvm-commits
Differential Revision: https://reviews.llvm.org/D47785
llvm-svn: 334165
|
|
|
|
|
|
| |
Create a separate feature set for Exynos M4 and add test cases.
llvm-svn: 334115
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Moves the Mode field out of the Key. The existing yaml benchmark results can be fixed with the following script:
```
readonly FILE=$1
readonly MODE=latency # Change to uops to fix a uops benchmark.
cat $FILE | \
sed "/^\ \+mode:\ \+$MODE$/d" | \
sed "/^cpu_name.*$/i mode: $MODE"
```
Differential Revision: https://reviews.llvm.org/D47813
Authored by: Guillaume Chatelet
llvm-svn: 334079
|
|
|
|
|
|
|
|
|
|
| |
We want llvm-exegesis to explore instructions (effect of initial register values, effect of operand selection). To enable this a BenchmarkResult muststore all the relevant data in its key. This patch starts adding such data. Here we simply allow to store the generated instructions, following patches will add operands and initial values for registers.
https://reviews.llvm.org/D47764
Authored by: Guilluame Chatelet
llvm-svn: 334008
|
|
|
|
|
|
|
|
|
|
| |
Review feedback from r328165. Split out just the one function from the
file that's used by Analysis. (As chandlerc pointed out, the original
change only moved the header and not the implementation anyway - which
was fine for the one function that was used (since it's a
template/inlined in the header) but not in general)
llvm-svn: 333954
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: YAML encoding is backwards-compatible.
Reviewers: gchatelet
Subscribers: tschuett, llvm-commits
Differential Revision: https://reviews.llvm.org/D47705
llvm-svn: 333886
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This re-lands r333797 with a fix for big endian systems.
Original commit message:
This isn't encountered anywhere inside LLVM, so I wrote a test case to expose the issue and verify that it is fixed.
The basic problem is that the macho_load_command union contains all load comamnd structs. Load command structs in 32-bit macho files can be 32-bit aligned instead of 64-bit aligned.
There are some strange circumstances in which this can be exposed in a 64-bit macho if the load commands are invalid or if a 32-bit aligned load command is used. In the past we've worked around this type of problem with changes like r264232.
llvm-svn: 333854
|
|
|
|
|
|
|
|
| |
Existing implementations of these methods do not require lazy materialization,
and switching to JITEvaluatedSymbol allows us to remove error checking on the
client side.
llvm-svn: 333835
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and using the latter in DIBuilder::createArtificialType and
DIBuilder::createObjectPointerType methods as well as introducing
mirroring DISubprogram::cloneWithFlags and
DIBuilder::createArtificialSubprogram methods.
The primary goal here is to add createArtificialSubprogram to support
a pass downstream while keeping the method consistent with the
existing ones and making sure we don't encourage changing already
created DI-nodes.
Reviewed By: aprantl
Differential Revision: https://reviews.llvm.org/D47615
llvm-svn: 333806
|
|
|
|
|
|
|
|
| |
This reverts commit r333803.
Still breaking on big endian. Will sort this out later.
llvm-svn: 333805
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This re-lands r333797 with a fix for big endian systems.
Original commit message:
This isn't encountered anywhere inside LLVM, so I wrote a test case to expose the issue and verify that it is fixed.
The basic problem is that the macho_load_command union contains all load comamnd structs. Load command structs in 32-bit macho files can be 32-bit aligned instead of 64-bit aligned.
There are some strange circumstances in which this can be exposed in a 64-bit macho if the load commands are invalid or if a 32-bit aligned load command is used. In the past we've worked around this type of problem with changes like r264232.
llvm-svn: 333803
|