| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
| |
Extra const in the StringRef argument meant that MSVC complained about it not correctly overriding from OperandPredicateMatcher::emitCxxPredicateExpr (which didn't have the const)
llvm-svn: 296138
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This isn't testable for AArch64 by itself so this patch also adds
support for constant immediates in the pattern and physical
register uses in the result.
The new IntOperandMatcher matches the constant in patterns such as
'(set $rd:GPR32, (G_XOR $rs:GPR32, -1))'. It's always safe to fold
immediates into an instruction so this is the first rule that will match
across multiple BB's.
The Renderer hierarchy is responsible for adding operands to the result
instruction. Renderers can copy operands (CopyRenderer) or add physical
registers (in particular %wzr and %xzr) to the result instruction
in any order (OperandMatchers now import the operand names from
SelectionDAG to allow renderers to access any operand). This allows us to
emit the result instruction for:
%1 = G_XOR %0, -1 --> %1 = ORNWrr %wzr, %0
%1 = G_XOR -1, %0 --> %1 = ORNWrr %wzr, %0
although the latter is untested since the matcher/importer has not been
taught about commutativity yet.
Added BuildMIAction which can build new instructions and mutate them where
possible. W.r.t the mutation aspect, MatchActions are now told the name of
an instruction they can recycle and BuildMIAction will emit mutation code
when the renderers are appropriate. They are appropriate when all operands
are rendered using CopyRenderer and the indices are the same as the matcher.
This currently assumes that all operands have at least one matcher.
Finally, this change also fixes a crash in
AArch64InstructionSelector::select() caused by an immediate operand
passing isImm() rather than isCImm(). This was uncovered by the other
changes and was detected by existing tests.
Depends on D29711
Reviewers: t.p.northover, ab, qcolombet, rovka, aditya_nandakumar, javed.absar
Reviewed By: rovka
Subscribers: aemerson, dberris, kristof.beyls, llvm-commits
Differential Revision: https://reviews.llvm.org/D29712
llvm-svn: 296131
|
| |
|
|
|
|
|
| |
The 'Kind' member used in RTTI for InstructionPredicateMatcher was not
initialized but went undetected since I always ended up with the correct value.
llvm-svn: 296126
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This makes more important rules have priority over less important rules.
For example, '%a = G_ADD $b:s64, $c:s64' has priority over
'%a = G_ADD $b:s32, $c:s32'. Previously these rules were emitted in the
correct order by chance.
NFC in this patch but it is required to make the next patch work correctly.
Depends on D29710
Reviewers: t.p.northover, ab, qcolombet, aditya_nandakumar, rovka
Reviewed By: ab, rovka
Subscribers: javed.absar, dberris, llvm-commits, kristof.beyls
Differential Revision: https://reviews.llvm.org/D29711
llvm-svn: 296121
|
| |
|
|
|
|
|
|
| |
clang will generate IR like this for input using packed bitfields;
very simple semantically, but it's a bit tricky to actually
generate good code.
llvm-svn: 296080
|
| |
|
|
|
|
| |
use llvm::to_string instead of std:: version.
llvm-svn: 295711
|
| |
|
|
|
|
| |
I will add one more use for this in a later change.
llvm-svn: 295685
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MachineOperand expr. NFC
Summary:
Each OperandPredicateMatcher shouldn't need to know how to generate the expression
to reference a MachineOperand. The OperandMatcher should provide it.
In addition to separating responsibilities, this also lays some groundwork for
decoupling source patterns from destination patterns to allow invented operands
or operands provided by GlobalISel's equivalent to the ComplexPattern<> class.
Depends on D29709
Reviewers: t.p.northover, ab, rovka, qcolombet, aditya_nandakumar
Reviewed By: ab
Subscribers: dberris, kristof.beyls, llvm-commits, igorb
Differential Revision: https://reviews.llvm.org/D29710
llvm-svn: 295668
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In the near future the rules will be sorted between these two steps to
ensure that more important rules are not prevented by less important ones.
Reviewers: t.p.northover, ab, rovka, qcolombet, aditya_nandakumar
Reviewed By: ab
Subscribers: dberris, kristof.beyls, llvm-commits
Differential Revision: https://reviews.llvm.org/D29709
llvm-svn: 295661
|
| |
|
|
|
|
|
|
|
|
|
| |
all AVX instructions with the new value.
Add WIG value to all of AVX instructions which ignore the W-bit in their encoding, instead of giving them the default value of 0.
This patch is needed for a follow up work on EVEX2VEX pass (replacing EVEX encoded instructions with their corresponding VEX version when possible).
Differential Revision: https://reviews.llvm.org/D29876
llvm-svn: 295643
|
| |
|
|
|
|
| |
This was found by another commit I'm working on.
llvm-svn: 295578
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Syntax highlighting has been done line-at-a-time. Done this way, the lexer
resets the context at each line, distorting the formatting.
This change will render the whole file at once and feed the highlighted text
line-at-a-time to be wrapped by the SourceFileRenderer.
Leading/trailing newlines were being ignored by Pygments but since each line
was rendered in its own row, it didn't matter. This bug was masked by the
line-at-a-time algorithm. So now we need to add "stripnl=False" to the
CppLexer to change its behavior to match the expectation.
llvm-svn: 295546
|
| |
|
|
|
|
|
|
|
|
| |
To help assist in debugging ISEL or to prioritize GlobalISel backend
work, this patch adds two more tables to <Target>GenISelDAGISel.inc -
one which contains the patterns that are used during selection and the
other containing include source location of the patterns
Enabled through CMake varialbe LLVM_ENABLE_DAGISEL_COV
llvm-svn: 295081
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows for nicer backtrace and debugging when -j1 is passed:
$ opt-viewer.py CMakeFiles/LLVMScalarOpts.dir/LoopVersioningLICM.cpp.opt.yaml html
Traceback (most recent call last):
File "/org/llvm/utils/opt-viewer/opt-viewer.py", line 405, in <module>
generate_report(pmap, all_remarks, file_remarks, args.source_dir, args.output_dir)
File "/org/llvm/utils/opt-viewer/opt-viewer.py", line 362, in generate_report
pmap(_render_file_bound, file_remarks.items())
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/multiprocessing/pool.py", line 251, in map
return self.map_async(func, iterable, chunksize).get()
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/multiprocessing/pool.py", line 567, in get
raise self._value
Exception: blah
$ opt-viewer.py -j 1 CMakeFiles/LLVMScalarOpts.dir/LoopVersioningLICM.cpp.opt.yaml html
Traceback (most recent call last):
File "/org/llvm/utils/opt-viewer/opt-viewer.py", line 405, in <module>
generate_report(pmap, all_remarks, file_remarks, args.source_dir, args.output_dir)
File "/org/llvm/utils/opt-viewer/opt-viewer.py", line 362, in generate_report
pmap(_render_file_bound, file_remarks.items())
File "/org/llvm/utils/opt-viewer/opt-viewer.py", line 317, in _render_file
SourceFileRenderer(source_dir, output_dir, filename).render(remarks)
File "/org/llvm/utils/opt-viewer/opt-viewer.py", line 168, in __init__
raise Exception("blah")
Exception: blah
llvm-svn: 295080
|
| |
|
|
|
|
|
| |
The `returned` keyword was added in SVN r179925. Update the vim syntax
rules.
llvm-svn: 294808
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Small fix to HtmlFormatter, defaults to ascii encoding, so utf-8 output may get `UnicodeEncodeError: 'ascii' codec can't encode character ... ordinal not in range(128)` during write.
Patch by Brian Cain!
Reviewers: anemet, fhahn
Reviewed By: anemet
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29802
llvm-svn: 294710
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of emitting the matcher code directly, return the rule matcher
and the skip reason as an Expected<RuleMatcher>.
This will let us record all matchers and process them before emission.
It's a somewhat unconventional use of Error, but it's nicer than, say,
std::pair, because of the bool conversions.
Differential Revision: https://reviews.llvm.org/D29743
llvm-svn: 294706
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Inside an alias group, when ordering instruction aliases, we rely
on the priority field to sort them.
When the priority is not set or more generally when there is a tie between
two aliases, we used to rely on the lexicographic order. However, this
order can change for the anonymous records when more instruction, intrinsic,
etc. are inserted.
For instance, given two anonymous records r1 and r2 with respective name
A_999 and A_1000, their lexicography order will be r2 then r1. Now, if
an instruction is added before them, their name will become respectively
A_1000 and A_1001, thus the lexicography order will be r1 then r2, i.e.,
it changed.
If that happens in an alias group, the assembly output would prefer a
different alias for no apparent good reasons.
A way to fix that is to use proper priority for all aliases, but we
can also make the tie breaker comparison smarter and use a deterministic
ordering. This is what this patch does.
llvm-svn: 294695
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LLVM defines `PTHREAD_LIB` which is used by AddLLVM.cmake and various projects
to correctly link the threading library when needed. Unfortunately
`PTHREAD_LIB` is defined by LLVM's `config-ix.cmake` file which isn't installed
and therefore can't be used when configuring out-of-tree builds. This causes
such builds to fail since `pthread` isn't being correctly linked.
This patch attempts to fix that problem by renaming and exporting
`LLVM_PTHREAD_LIB` as part of`LLVMConfig.cmake`. I renamed `PTHREAD_LIB`
because It seemed likely to cause collisions with downstream users of
`LLVMConfig.cmake`.
llvm-svn: 294690
|
| |
|
|
|
|
|
|
|
|
| |
Passing the --restrict flag to the coverage prep script before other
positional arguments is wrong, because it prevents the argparse module
from telling apart arguments to --restrict versus positional arguments.
Pointed out by Sean Callanan!
llvm-svn: 294616
|
| |
|
|
|
|
| |
'const' on StringRef parameters adds no guarantees. Remove it.
llvm-svn: 294555
|
| |
|
|
| |
llvm-svn: 294523
|
| |
|
|
|
|
|
|
|
|
|
| |
In r293373 we switched the build to linking dynamically against the
Universal CRT and include the redistributables in the installer.
However, clang-format.exe is copied into the vsix and needs to be
statically linked. This commit makes us build the plugin in a separate
step that uses static linking.
llvm-svn: 294513
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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:
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
|
| |
|
|
|
|
|
|
| |
Refactor a helper function, FactorNodes, to search for a push node in constant space. This resolves a problem in a not-yet-upstreamed backend where a recursive pattern blew the call stack (at a depth of 255) under a debug build of tablegen. No functional change so no new test coverage. The change is minimal to avoid disturbing existing behaviour.
Differential Revision: https://reviews.llvm.org/D29080
llvm-svn: 294230
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Building lld is enabled by default, but it can be disabled using the
-no-lld option.
Reviewers: tstellarAMD, rengolin, hans
Reviewed By: hans
Subscribers: grosser, wdng, emaste, llvm-commits
Differential Revision: https://reviews.llvm.org/D29539
llvm-svn: 294102
|
| |
|
|
|
|
| |
Based on a review of D29478 by Kristof Beyls.
llvm-svn: 294077
|
| |
|
|
|
|
|
|
| |
This lets us split out PatternToMatch from the top-level RuleMatcher,
where it doesn't really belong. That, in turn, lets us eventually
generate RuleMatchers from non-SelectionDAG sources.
llvm-svn: 294076
|
| |
|
|
|
|
|
| |
We don't try very hard to format the emitted code, but newlines
are an easy way to make it more readable.
llvm-svn: 294074
|
| |
|
|
|
|
| |
The instruction selector has been emitting the register bank information too.
llvm-svn: 294007
|
| |
|
|
| |
llvm-svn: 293869
|
| |
|
|
| |
llvm-svn: 293868
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: aditya_nandakumar, rovka, t.p.northover, qcolombet, ab
Subscribers: dberris, llvm-commits, kristof.beyls
Differential Revision: https://reviews.llvm.org/D29321
llvm-svn: 293760
|
| |
|
|
|
|
|
|
|
|
| |
Fixed wrong paths in comments for *.vim files.
Patch By: Bruno Rosa (brunoalr)
Differential Revision: https://reviews.llvm.org/D29174
llvm-svn: 293693
|
| |
|
|
|
|
|
|
|
| |
Use the qualified name for StringLiteral (llvm::StringLiteral) when
generating the sources. This is needed as the generated files may be
used out-of-tree (e.g. swift) where you may not have a
`using namespace llvm;` resulting in an undefined lookup.
llvm-svn: 293577
|
| |
|
|
|
|
| |
This is fairly ugly, but apparently GCC still doesn't understand C++11.
llvm-svn: 293535
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Tablegen emitted a warning when the fast isel emitter created dead
code by emitting a pattern that has no predicate before a pattern
that has one.
This should be an error but was originally only a warning because the X86
backend had a buggy definition that unintentionally caused this to be hit
(PR21575). That has been fixed a while ago (r222094), so it's safe to
upgrade the warning to an error.
llvm-svn: 293534
|
| |
|
|
| |
llvm-svn: 293528
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
AMDGPU has two register classes with the same set of registers, and this
was causing this tablegen backend would get stuck in infinite recursion.
Reviewers: dsanders
Reviewed By: dsanders
Subscribers: tpr, wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D29049
llvm-svn: 293483
|
| |
|
|
|
|
|
|
| |
r293172
It's now emitCxxPredicateListExpr() to better match the class name.
llvm-svn: 293376
|
| |
|
|
|
|
|
|
|
|
|
|
| |
on Windows.
In order to make sure that LLVM continues to work on machines that do not have the Universal CRT yet,
we'll need to ship a copy of UCRT in the Windows installation package. Fortunately, CMake 3.6+ already
supports app-local deployment of UCRT dlls, we just need to turn this on.
Differential Revision: https://reviews.llvm.org/D29146
llvm-svn: 293373
|
| |
|
|
|
|
|
| |
The dump() functions are meant to be used in a debugger, code should
typically use something like print(errs());
llvm-svn: 293365
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We had various variants of defining dump() functions in LLVM. Normalize
them (this should just consistently implement the things discussed in
http://lists.llvm.org/pipermail/cfe-dev/2014-January/034323.html
For reference:
- Public headers should just declare the dump() method but not use
LLVM_DUMP_METHOD or #if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP)
- The definition of a dump method should look like this:
#if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP)
LLVM_DUMP_METHOD void MyClass::dump() {
// print stuff to dbgs()...
}
#endif
llvm-svn: 293359
|
| |
|
|
|
|
|
| |
This is necessary since globals (max_hotness, caller_loc) need to be
explicitly passed to the subprocesses.
llvm-svn: 293266
|
| |
|
|
|
|
|
|
| |
This is causing problems because the rendering of the text will depend on
varying global state to show relative hotness or a link in the inlining
context.
llvm-svn: 293265
|
| |
|
|
| |
llvm-svn: 293264
|
| |
|
|
|
|
| |
Break the tie between entries with identical hotness deterministically.
llvm-svn: 293263
|
| |
|
|
|
|
| |
Avoid uniquing remarks with different the inlining context (Function).
llvm-svn: 293262
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Put opt-viewer critical items in parallel
Patch by Brian Cain!
Requires features from Python 2.7
**Performance**
Below are performance results across various configurations. These were taken on an i5-5200U (dual core + HT). They were taken with a small subset of the YAML output of building Python 3.6.0b3 with LTO+PGO. 60 YAML files.
"multiprocessing" is the current submission contents. "baseline" is as of 544f14c6b2a07a94168df31833dba9dc35fd8289 (I think this is aka r287505).
"ImportError" vs "class<...CLoader>" below are just confirming the expected configuration (with/without CLoader).
The below was measured on AMD A8-5500B (4 cores) with 224 input YAML files, showing a ~1.75x speed increase over the baseline with libYAML. I suspect it would scale well on high-end servers.
```
**************************************** MULTIPROCESSING ****************************************
PyYAML:
Traceback (most recent call last):
File "<string>", line 1, in <module>
ImportError: cannot import name CLoader
Python 2.7.10
489.42user 5.53system 2:38.03elapsed 313%CPU (0avgtext+0avgdata 400308maxresident)k
0inputs+31392outputs (0major+473540minor)pagefaults 0swaps
PyYAML+libYAML:
<class 'yaml.cyaml.CLoader'>
Python 2.7.10
78.69user 5.45system 0:32.63elapsed 257%CPU (0avgtext+0avgdata 398560maxresident)k
0inputs+31392outputs (0major+542022minor)pagefaults 0swaps
PyPy/PyYAML:
Traceback (most recent call last):
File "<builtin>/app_main.py", line 75, in run_toplevel
File "<builtin>/app_main.py", line 601, in run_it
File "<string>", line 1, in <module>
ImportError: cannot import name 'CLoader'
Python 2.7.9 (2.6.0+dfsg-3, Jul 04 2015, 05:43:17)
[PyPy 2.6.0 with GCC 4.9.3]
154.27user 8.12system 0:53.83elapsed 301%CPU (0avgtext+0avgdata 627960maxresident)k
808inputs+30376outputs (0major+727994minor)pagefaults 0swaps
**************************************** BASELINE ****************************************
PyYAML:
Traceback (most recent call last):
File "<string>", line 1, in <module>
ImportError: cannot import name CLoader
Python 2.7.10
358.08user 4.05system 6:08.37elapsed 98%CPU (0avgtext+0avgdata 315004maxresident)k
0inputs+31392outputs (0major+85252minor)pagefaults 0swaps
PyYAML+libYAML:
<class 'yaml.cyaml.CLoader'>
Python 2.7.10
50.32user 3.30system 0:56.59elapsed 94%CPU (0avgtext+0avgdata 307296maxresident)k
0inputs+31392outputs (0major+79335minor)pagefaults 0swaps
PyPy/PyYAML:
Traceback (most recent call last):
File "<builtin>/app_main.py", line 75, in run_toplevel
File "<builtin>/app_main.py", line 601, in run_it
File "<string>", line 1, in <module>
ImportError: cannot import name 'CLoader'
Python 2.7.9 (2.6.0+dfsg-3, Jul 04 2015, 05:43:17)
[PyPy 2.6.0 with GCC 4.9.3]
72.94user 5.18system 1:23.41elapsed 93%CPU (0avgtext+0avgdata 455312maxresident)k
0inputs+30392outputs (0major+110280minor)pagefaults 0swaps
```
Reviewers: fhahn, anemet
Reviewed By: anemet
Subscribers: llvm-commits, mehdi_amini
Differential Revision: https://reviews.llvm.org/D26967
llvm-svn: 293261
|