| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
iterate the set anyway. NFCI.
llvm-svn: 340055
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We were just caching the MVT set of legal types, then every call creating a new TypeSetByHwMode with it and passing it back on the stack. There's no need to do this - we can create and cache the whole TypeSetByHwMode once and return a const reference to it each time.
Additionally, TypeInfer::expandOverloads wasn't making use of the fact that the cache just contains a default mode containing all the types.
Saves up to 30secs in debug builds of x86 -gen-dag-isel.
Differential Revision: https://reviews.llvm.org/D50903
llvm-svn: 340042
|
| |
|
|
|
|
| |
Avoids repeated count()/find() calls that we've already have the default values for.
llvm-svn: 340020
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This operator is called a great deal, by checking for the cheap isSimple equality cases first (a common occurrence) we can improve performance as we avoid a lot of std::map find/iteration in hasDefault.
isSimple also means that a default value is present, so we can avoid some hasDefault calls.
This also avoids a rather dodgy piece of logic that was checking for isSimple() && !VTS.isSimple() but not the inverse - it now uses the general hasDefault mode comparison test instead.
Saves around 15secs in debug builds of x86 -gen-dag-isel.
Differential Revision: https://reviews.llvm.org/D50841
llvm-svn: 339890
|
| |
|
|
|
|
| |
We were performing a completely unnecessary full comparison of the same std::vector<Predicate>.
llvm-svn: 339888
|
| |
|
|
|
|
|
|
| |
CodeGenRegisterClass::getValueTypeNum
Avoids costly std::map copies inside ValueTypeByHwMode constructor
llvm-svn: 339884
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
TypeSetByHwMode conversions in getPatternSize
I noticed this during profiling of tablegen (PR28222) that we were calling Child->getType(0) which creates a ValueTypeByHwMode on the fly from the requested internal TypeSetByHwMode type and returns it by value, we then treat it as a TypeSetByHwMode reference which involves constructing a new TypeSetByHwMode on the stack with a large amount of std::map iterating/copying all along the way.
I am not an expert on tablegen, but AFAICT this is all unnecessary and we should be calling Child->getExtType(0) which returns the original TypeSetByHwMode by reference.
This gives me a 90sec reduction in msvc debug builds of x86 -gen-dag-isel.
Differential Revision: https://reviews.llvm.org/D50789
llvm-svn: 339812
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TIIPredicate, and implemented verification rules for TIIPredicates.
This patch removes redundant template argument `TargetName` from TIIPredicate.
Tablegen can always infer the target name from the context. So we don't need to
force users of TIIPredicate to always specify it.
This allows us to better modularize the tablegen class hierarchy for the
so-called "function predicates". class FunctionPredicateBase has been added; it
is currently used as a building block for TIIPredicates. However, I plan to
reuse that class to model other function predicate classes too (i.e. not just
TIIPredicates). For example, this can be a first step towards implementing
proper support for dependency breaking instructions in tablegen.
This patch also adds a verification step on TIIPredicates in tablegen.
We cannot have multiple TIIPredicates with the same name. Otherwise, this will
cause build errors later on, when tablegen'd .inc files are included by cpp
files and then compiled.
Differential Revision: https://reviews.llvm.org/D50708
llvm-svn: 339706
|
| |
|
|
| |
llvm-svn: 339670
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
selection of relative jumps in 16-bit mode. Treat jno/jo like other jcc instructions.
The behavior in 64-bit mode is different between Intel and AMD CPUs. Intel ignores the 0x66 prefix. AMD does not. objump doesn't ignore the 0x66 prefix. Since LLVM aims to match objdump behavior, we should do the same.
While I was trying to fix this I had change brtarget16/32 to use ENCODING_IW/ID instead of ENCODING_Iv to get the 0x66+REX.W case to act sort of sanely. It's still wrong, but that's a problem for another day.
The change in encoding exposed the fact that 16-bit mode disassembly of relative jumps was creating JMP_4 with a 2 byte immediate. It should have been JMP_2. From just printing you can't tell the difference, but if you dumped the encoding it wouldn't have matched what we started with.
While fixing that, it exposed that jo/jno opcodes were missing from the switch that this patch deleted and there were no test cases for them.
Fixes PR38537.
llvm-svn: 339622
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
predicate expander. NFCI
This is a follow-up of r339552.
As pointed out by Craig in D50566, we don't need a formatted_raw_ostream to
indent strings. We can use instead raw_ostream::indent().
Internally, class PredicateExpander already keeps track of the current
indentation level. Also, the grammar for predicates is well parenthesized, and
therefore we don't need to use a formatted_raw_ostream to continuously track the
column number. Instead we can safely replace all the uses of
formatted_raw_ostream::PadToColumn() with uses of raw_ostream::indent().
By replacing formatted_raw_ostream with a simpler raw_ostream, we also avoid the
implicit check on the newline character on every print to stream.
No functional change intended.
llvm-svn: 339577
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
scheduling class.
This patch refactors the logic that expands predicates of a variant scheduling
class.
The idea is to improve the readability of the auto-generated code by removing
redundant parentheses around predicate expressions, and by removing redundant
if(true) statements.
This patch replaces the definition of NoSchedPred in TargetSchedule.td with an
instance of MCSchedPredicate. The new definition is sematically equivalent to
the previous one. The main difference is that now SubtargetEmitter knows that it
represents predicate "true".
Before this patch, we always generated an if (true) for the default transition
of a variant scheduling class.
Example (taken from AArch64GenSubtargetInfo.inc) :
```
if (SchedModel->getProcessorID() == 3) { // CycloneModel
if ((TII->isScaledAddr(*MI)))
return 927; // (WriteIS_WriteLD)_ReadBaseRS
if ((true))
return 928; // WriteLD_ReadDefault
}
```
Extra parentheses were also generated around the predicate expressions.
With this patch, we get the following auto-generated checks:
```
if (SchedModel->getProcessorID() == 3) { // CycloneModel
if (TII->isScaledAddr(*MI))
return 927; // (WriteIS_WriteLD)_ReadBaseRS
return 928; // WriteLD_ReadDefault
}
```
The new auto-generated code behaves exactly the same as before. So, technically
this is a non functional change.
Differential revision: https://reviews.llvm.org/D50566
llvm-svn: 339552
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Found by GCC's -Wunused-function.
Patch by Kim Gräsman
Reviewers: ab, dsanders, llvm-commits
Reviewed By: dsanders
Subscribers: rovka, kristof.beyls
Differential Revision: https://reviews.llvm.org/D50611
llvm-svn: 339528
|
| |
|
|
|
|
|
|
|
|
| |
Part of the logic has been moved to helper functions to (hopefully) improve
readability.
Added a few code comments to better describe how the algorithm works.
No functional change intended.
llvm-svn: 339421
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
return statements.
This patch introduces tablegen class MCStatement.
Currently, an MCStatement can be either a return statement, or a switch
statement.
```
MCStatement:
MCReturnStatement
MCOpcodeSwitchStatement
```
A MCReturnStatement expands to a return statement, and the boolean expression
associated with the return statement is described by a MCInstPredicate.
An MCOpcodeSwitchStatement is a switch statement where the condition is a check
on the machine opcode. It allows the definition of multiple checks, as well as a
default case. More details on the grammar implemented by these two new
constructs can be found in the diff for TargetInstrPredicates.td.
This patch makes it easier to read the body of auto-generated TargetInstrInfo
predicates.
In future, I plan to reuse/extend the MCStatement grammar to describe more
complex target hooks. For now, this is just a first step (mostly a minor
cosmetic change to polish the new predicates framework).
Differential Revision: https://reviews.llvm.org/D50457
llvm-svn: 339352
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The interface to get size and spill size of a register
was moved from MCRegisterInfo to TargetRegisterInfo over
a year ago. Afaik the old interface has bee around
to give out-of-tree targets a chance to adapt to the
new interface.
One problem with the old MCRegisterClass::PhysRegSize was that
it represented the size of a register as "size in bits" / 8.
So a register had to be a multiple of eight bits wide for the
size to be correct (and the byte size for the target needed to
be eight bits).
Reviewers: kparzysz, qcolombet
Reviewed By: kparzysz
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D47199
llvm-svn: 339350
|
| |
|
|
|
|
|
|
|
|
|
| |
Changes the default Windows target triple returned by
GetHostTriple.cmake from the old environment names (which we wanted to
move away from) to newer, normalized ones. This also requires updating
all tests to use the new systems names in constraints.
Differential Revision: https://reviews.llvm.org/D47381
llvm-svn: 339307
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
barely-necessary std::map with a sorted vector
Summary:
This particular map is hardly ever queried and has a phased usage pattern (insert,
iterate, query, insert, iterate) so it's a good candidate for a sorted vector and
std::lower_bound.
This significantly reduces the run time of runTargetDesc() in some circumstances.
One llvm-tblgen invocation in my build improves the time spent in runTargetDesc()
from 9.86s down to 0.80s (~92%) without changing the output. The same invocation
also has 2GB less allocation churn.
Reviewers: bogner, rtereshin, aditya_nandakumar, volkan
Reviewed By: rtereshin
Subscribers: mgrang, dexonsmith, llvm-commits
Differential Revision: https://reviews.llvm.org/D50272
llvm-svn: 339208
|
| |
|
|
|
|
|
|
|
|
| |
https://reviews.llvm.org/D50283
reviewed by bogner
This patch refactors FileCheck's implementation into support so it can
be used from C++ in other places (Unit tests).
llvm-svn: 339192
|
| |
|
|
|
|
| |
This test passes on Windows when using Python 3 but fails when using Python 2, so it needs more investigation before it can be enabled as the bots use Python 2.
llvm-svn: 339184
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
other test fixes
Summary:
In Python2 'unicode' is a distinct type from 'str', but in Python3 'unicode' does not exist and instead all 'str' objects are Unicode string. This change updates the logic in the test logging for lit to correctly process each of the types, and more importantly, to not just fail in Python3.
This change also reverses the use of quotes in several of the cfg files. By using '""' we are guaranteeing that the resulting path will work correctly on Windows while "''" only works correctly sometimes. This also fixes one of the failing tests.
Reviewers: asmith, zturner
Subscribers: stella.stamenova, delcypher, llvm-commits
Differential Revision: https://reviews.llvm.org/D50397
llvm-svn: 339179
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The problem here is that on windows double quotes are used for paths (usually) while single quotes are not. This is not generally a problem for the tests because the lit infrastructure tends to treat both the same. One (and possibly only) exception is when some tests are run in an external shell such as some of the shtest-format tests. In this case on windows the path to python was not created correctly because it had single quotes and the test failed.
This same test is already failing with python 3 which is why our testing missed the new failure. This patch will take care of the immediate failure with python 2 and I'll send a follow up for the python 3 failure.
Reviewers: asmith, zturner
Subscribers: delcypher, llvm-commits
Differential Revision: https://reviews.llvm.org/D50373
llvm-svn: 339091
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The issue with the python path is that the path to python on Windows can contain spaces. To make the tests always work, the path to python needs to be surrounded by quotes.
This change updates several configuration files which specify the path to python as a substitution and also remove quotes from existing tests.
Reviewers: asmith, zturner, alexshap, jakehehrlich
Reviewed By: zturner, alexshap, jakehehrlich
Subscribers: mehdi_amini, nemanjai, eraman, kbarton, jakehehrlich, steven_wu, dexonsmith, stella.stamenova, delcypher, llvm-commits
Differential Revision: https://reviews.llvm.org/D50206
llvm-svn: 339073
|
| |
|
|
| |
llvm-svn: 339029
|
| |
|
|
|
|
| |
After r338721, it builds again.
llvm-svn: 338823
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Was:
int LongVariableName =
veryLongFunctionNameThatExceeds80ColumnsRule(SomeParameter);
int ShortVar = veryLongFunctionNameThatStillFitsIntoOneLine(SomeParameter)
.nowThisDoesntFit()
.andThis()
Now:
int LongVariableName =
veryLongFunctionNameThatExceeds80ColumnsRule(SomeParameter);
int ShortVar = veryLongFunctionNameThatStillFitsIntoOneLine(SomeParameter)
.nowThisDoesntFit()
.andThis()
Reviewers: espindola, MaskRay
Reviewed By: MaskRay
Subscribers: greened, llvm-commits
Differential Revision: https://reviews.llvm.org/D49726
llvm-svn: 338686
|
| |
|
|
| |
llvm-svn: 338682
|
| |
|
|
| |
llvm-svn: 338677
|
| |
|
|
| |
llvm-svn: 338537
|
| |
|
|
| |
llvm-svn: 338522
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The DAG combiner logic to simplify AND masks in shift counts is invalid.
While it is true that the SystemZ shift instructions ignore all but the
low 6 bits of the shift count, it is still invalid to simplify the AND
masks while the DAG still uses the standard shift operators (which are
*not* defined to match the SystemZ instruction behavior).
Instead, this patch performs equivalent operations during instruction
selection. For completely removing the AND, this now happens via
additional DAG match patterns implemented by a multi-alternative
PatFrags. For simplifying a 32-bit AND to a 16-bit AND, the existing DAG
patterns were already mostly OK, they just needed an output XForm to
actually truncate the immediate value.
Unfortunately, the latter change also exposed a bug in TableGen: it
seems XForms are currently only handled correctly for direct operands of
the outermost operation node. This patch also fixes that bug by simply
recurring through the whole pattern. This should be NFC for all other
targets.
Differential Revision: https://reviews.llvm.org/D50096
llvm-svn: 338521
|
| |
|
|
|
|
|
|
| |
https://reviews.llvm.org/D49243
Contains WIP code that should not have been included.
llvm-svn: 338369
|
| |
|
|
|
|
| |
https://reviews.llvm.org/D49243
llvm-svn: 338365
|
| |
|
|
| |
llvm-svn: 338202
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The VS compiler (on Windows) has a bug which results in fieldFromInstruction being optimized out in some circumstances. This only happens in *release no debug info* builds that have assertions *turned off* - in all other situations the function is not inlined, so the functionality is correct. All of the bots have assertions turned on, so this path is not regularly tested. The workaround is to not inline the function on Windows - if the bug is fixed in a later release of the VS compiler, the noinline specification can be removed.
The test that consistently reproduces this is Lanai v11.txt test.
Reviewers: asmith, labath, zturner
Subscribers: dblaikie, stella.stamenova, aprantl, JDevlieghere, llvm-commits
Differential Revision: https://reviews.llvm.org/D49753
llvm-svn: 337942
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
LLVM_ENABLE_PROJECTS expects a semicolon separated project list.
Fixes PR38158.
Reviewers: ilya-biryukov
Reviewed By: ilya-biryukov
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D49712
llvm-svn: 337842
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The llvm::Optional data formatter needs to look through the `Storage`
container if it's present.
Before:
220 if (Op && Op->getOp() != dwarf::DW_OP_LLVM_fragment)
-> 221 HasComplexExpression = true;
222
223 // If the register can only be described by a complex expression (i.e.,
224 // multiple subregisters) it doesn't safely compose with another complex
Target 0: (llc) stopped.
(lldb) p Op
(llvm::Optional<llvm::DIExpression::ExprOperand>) $0 = None
After:
(lldb) p Op
(llvm::Optional<llvm::DIExpression::ExprOperand>) $0 =
(llvm::DIExpression::ExprOperand) storage = {
Op = 0x000000010603d460
}
llvm-svn: 337752
|
| |
|
|
| |
llvm-svn: 337747
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
models"
Don't try to generate large PIC code for non-ELF targets. Neither COFF
nor MachO have relocations for large position independent code, and
users have been using "large PIC" code models to JIT 64-bit code for a
while now. With this change, if they are generating ELF code, their
JITed code will truly be PIC, but if they target MachO or COFF, it will
contain 64-bit immediates that directly reference external symbols. For
a JIT, that's perfectly fine.
llvm-svn: 337740
|
| |
|
|
|
|
|
|
| |
These two tests are operating on the same test suite, which causes
them to be racy about writing temporary files and can cause spurious
failures. Merge them into one test to avoid the issue.
llvm-svn: 337718
|
| |
|
|
|
|
|
| |
Recent changes to the internal structure of SmallVector<> broke
all of the MSVC visualizers. This fixes them.
llvm-svn: 337644
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
on failure
The option can be either set using environment variable (e.g. env
FILECHECK_DUMP_INPUT_ON_FAILURE=1 ninja check-fuzzer) or with a
FileCheck flag.
This can be extremely useful for debugging, cf.
https://groups.google.com/forum/#!topic/llvm-dev/kLrzg8OM_h8 for
discussion.
Differential Revision: https://reviews.llvm.org/D49328
llvm-svn: 337609
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A DAG-NOT-DAG is a CHECK-DAG group, X, followed by a CHECK-NOT group,
N, followed by a CHECK-DAG group, Y. Let y be the initial directive
of Y. This patch makes the following changes to the behavior:
1. Directives in N can no longer match within part of Y's match
range just because y happens not to be the earliest match from
Y. Specifically, this patch withdraws N's search range end
from y's match range start to Y's match range start.
2. y can no longer match within X's match range, where a y match
produced a reordering complaint, which is thus no longer
possible. Specifically, this patch withdraws y's search range
start from X's permitted range start to X's match range end,
which was already the search range start for other members of
Y.
Both of these changes can only increase the number of test passes: #1
constrains the ability of CHECK-NOTs to match, and #2 expands the
ability of CHECK-DAGs to match without complaints.
These changes are based on discussions at:
<http://lists.llvm.org/pipermail/llvm-dev/2018-May/123550.html>
<https://reviews.llvm.org/D47106>
which conclude that:
1. These changes simplify the FileCheck conceptual model. First,
it makes search ranges for DAG-NOT-DAG more consistent with
other cases. Second, it was confusing that y was treated
differently from the rest of Y.
2. These changes add theoretical use cases for DAG-NOT-DAG that
had no obvious means to be expressed otherwise. We can justify
the first half of this assertion with the observation that
these changes can only increase the number of test passes.
3. Reordering detection for DAG-NOT-DAG had no obvious real
benefit.
We don't have evidence from real uses cases to help us debate
conclusions #2 and #3, but #1 at least seems intuitive.
Reviewed By: probinson
Differential Revision: https://reviews.llvm.org/D48986
llvm-svn: 337605
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is very clearly not very good, and is very partial.
But this is better than nothing at all, and shouldn't
hurt those who don't need it.
If there are others interested in this functionality,
it will be great to further improve this.
{F6253091}
Reviewed By: Bigcheese
Differential Revision: https://reviews.llvm.org/D47080
llvm-svn: 337415
|
| |
|
|
|
|
|
|
| |
registers.
This was discussed in review D49436.
llvm-svn: 337378
|
| |
|
|
|
|
|
|
|
|
| |
Function `expandCheckImmOperand` should always check if the input machine
instruction is passed by reference before calling method `getOperand()` on it.
Found while working on a patch that relies on `expandCheckImmOperand` to expand
a scheduling predicate.
llvm-svn: 337294
|
| |
|
|
| |
llvm-svn: 337121
|
| |
|
|
|
|
| |
The comment says the copy was made so it could be destroyed in the following loop, but the original map wasn't used after the loop.
llvm-svn: 337120
|
| |
|
|
|
|
| |
The are two vectors passed by value to the constructor. We should be able to move them into the object.
llvm-svn: 337114
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, any attempt to define a PatFrag involving any floating-point
only (or vector only) node causes a hard assertion failure in TableGen
if the current target does not have any floating-point (or vector)
types.
This is annoying if you want to provide convenience fragments in common
code (e.g. include/llvm/Target/TargetSelectionDAG.td) that is parsed on
all platforms, including those that miss such types.
But really, there's no reason not accept this when parsing the fragment
-- of course it would be an error for such a target to actually *use*
such a fragment anywhere, but as long as it doesn't, I think TableGen
shouldn't error out.
The immediate cause of the assertion failure is the test inside the
ValidateOnExit destructor. This patch simply disables that check while
infering types during parsing of pattern fragments (only).
Reviewed By: hfinkel, kparzysz
Differential Revision: https://reviews.llvm.org/D48887
llvm-svn: 337023
|