The ISD::STRICT_ nodes used to implement the constrained floating-point
intrinsics are currently never passed to the target back-end, which makes
it impossible to handle them correctly (e.g. mark instructions are depending
on a floating-point status and control register, or mark instructions as
possibly trapping).
This patch allows the target to use setOperationAction to switch the action
on ISD::STRICT_ nodes to Legal. If this is done, the SelectionDAG common code
will stop converting the STRICT nodes to regular floating-point nodes, but
instead pass the STRICT nodes to the target using normal SelectionDAG
matching rules.
To avoid having the back-end duplicate all the floating-point instruction
patterns to handle both strict and non-strict variants, we make the MI
codegen explicitly aware of the floating-point exceptions by introducing
two new concepts:
- A new MCID flag "mayRaiseFPException" that the target should set on any
instruction that possibly can raise FP exception according to the
architecture definition.
- A new MI flag FPExcept that CodeGen/SelectionDAG will set on any MI
instruction resulting from expansion of any constrained FP intrinsic.
Any MI instruction that is *both* marked as mayRaiseFPException *and*
FPExcept then needs to be considered as raising exceptions by MI-level
codegen (e.g. scheduling).
Setting those two new flags is straightforward. The mayRaiseFPException
flag is simply set via TableGen by marking all relevant instruction
patterns in the .td files.
The FPExcept flag is set in SDNodeFlags when creating the STRICT_ nodes
in the SelectionDAG, and gets inherited in the MachineSDNode nodes created
from it during instruction selection. The flag is then transfered to an
MIFlag when creating the MI from the MachineSDNode. This is handled just
like fast-math flags like no-nans are handled today.
This patch includes both common code changes required to implement the
new features, and the SystemZ implementation.
Reviewed By: andrew.w.kaylor
Differential Revision: https://reviews.llvm.org/D55506
llvm-svn: 362663
A std::array is implemented as a template with an array inside a struct.
Older versions of clang, like 3.6, require an extra set of curly braces
around std::array initializations to avoid warnings.
The C++ language was changed regarding this by CWG 1270. So more modern
tool chains does not complain even if leaving out one level of braces.
llvm-svn: 362360
This changed updates the MSVC Visualizer to work with the recent change
of PointerUnion into a variadic template. As an extra bonus, we
fix some bit rot in the SmallPtrSet visualizer as well
llvm-svn: 362345
Fix the misleadingly indentation introduced in rL362064. This will get rid of
the compiler warning, and it was actually a bug. This change will be used and
tested in D62669.
llvm-svn: 362211
If an assembly instruction has to mention an input operand name twice,
for example the MVE VMOV instruction that accesses two lanes of the
same vector by writing 'vmov r1, r2, q0[3], q0[1]', then the obvious
way to write its AsmString is to include the same operand (here $Qd)
twice. But this causes the AsmMatcher generator to omit that
instruction completely from the match table, on the basis that the
generator isn't clever enough to deal with the duplication.
But you need to have _some_ way of dealing with an instruction like
this - and in this case, where the mnemonic is shared with many other
instructions that the AsmMatcher does handle, it would be very painful
to take it out of the AsmMatcher system completely.
A nicer way is to add a custom AsmMatchConverter routine, and let that
deal with the problem if the autogenerated converter can't. But that
doesn't work, because TableGen leaves the instruction out of its table
_even_ if you provide a custom converter.
Solution: this change, which makes TableGen relax the restriction on
duplicated operands in the case where there's a custom converter.
Patch by: Simon Tatham
Differential Revision: https://reviews.llvm.org/D60695
llvm-svn: 362066
This is a new special identifier which you can use as a default in
OperandWithDefaultOps. The idea is that you use it for an input
operand of an instruction that's tied to an output operand, and its
semantics are that (in the default case) the input operand's value is
not used at all.
The detailed effect is that when instruction selection emits the
instruction in the form of a pre-regalloc MachineInstr, it creates an
IMPLICIT_DEF node to use as that input.
If you're creating an MCInst with explicit register names, then the
right handling would be to set the input operand to the same register
as the output one (honouring the tie) and to add the 'undef' flag
indicating that that register is deemed to acquire a new don't-care
definition just before we read it. But I haven't done that in this
commit, because there was no need to - no Tablegen backend seems to
autogenerate default fields in an MCInst.
Patch by: Simon Tatham
Differential Revision: https://reviews.llvm.org/D60696
llvm-svn: 362064
Summary: This also normalizes the config feature that represents the windows platform to "system-windows" as opposed to having both "windows" and "system-windows"
Reviewers: asmith, probinson
Subscribers: delcypher, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D61798
llvm-svn: 361998
Summary:
clangd needs them to function properly, even though they are not
strictly required for the build.
Reviewers: thakis
Reviewed By: thakis
Subscribers: MaskRay, jkorous, arphaman, llvm-commits, kadircet
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62480
llvm-svn: 361828
Summary:
Appears identical to powerpc64{,le}.
Regenerate test that is being affected by upcoming patch.
Reviewers: RKSimon
Reviewed By: RKSimon
Subscribers: nemanjai, jsji, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62339
llvm-svn: 361543
Summary:
A commit may, for some reason, have `llvm-svn:` in it multiple times. It may even take up the whole line and look identical to what gets added automatically when svn commits land in github.
To workaround this, make changes to both lookups:
1) When doing the git -> svn lookup, make sure to go through the whole message, and:
a) Only look for llvm-svn starting at the beginning of the line (excluding the whitespace that `git log` adds).
b) Take the last one (at the end of the commit message), if there are multiple matches.
2) When doing the svn -> git lookup, look through a sizeable but still reasonably small number of git commits (10k, about 4-5 months right now), and:
a) Only consider commits with the '^llvm-svn: NNNNNN' we expect, and
b) Only consider those that also follow the same git -> svn matching above. (Error if it's not exactly one commit).
Reviewers: jyknight
Reviewed By: jyknight
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D60017
llvm-svn: 361532
Again, a mixture of march and triple, with majority being march:
llvm/test/CodeGen/Mips$ grep -ri triple | wc -l
818
llvm/test/CodeGen/Mips$ grep -ri march | wc -l
1457
llvm-svn: 361521
Summary:
Terminology introduced by [[#]] blocks is confusing and does not
integrate well with existing terminology.
First, variables referred by [[]] blocks are called "pattern variables"
while the text a CHECK directive needs to match is called a "CHECK
pattern". This is inconsistent with variables in [[#]] blocks since
[[#]] blocks are also found in CHECK pattern yet those variables are
called "numeric variable".
Second, the replacing of both [[]] and [[#]] blocks by the value of the
variable or expression they contain is represented by a
FileCheckPatternSubstitution class. The naming refers to being a
substitution in a CHECK pattern but could be wrongly understood as being
a substitution of a pattern variable.
Third and lastly, comments use "numeric expression" to refer both to the
[[#]] blocks as well as to the numeric expressions these blocks contain
which get evaluated at match time.
This patch solves these confusions by
- calling variables in [[]] and [[#]] blocks as string and numeric
variables respectively;
- referring to [[]] and [[#]] as substitution *blocks*, with the former
being a string substitution block and the latter a numeric
substitution block;
- calling [[]] and [[#]] blocks to be replaced by the value of a
variable or expression they contain a substitution (as opposed to
definition when these blocks are used to defined a variable), with the
former being a string substitution and the latter a numeric
substitution;
- renaming the FileCheckPatternSubstitution as a FileCheckSubstitution
class with FileCheckStringSubstitution and
FileCheckNumericSubstitution subclasses;
- restricting the use of "numeric expression" to refer to the expression
that is evaluated in a numeric substitution.
While numeric substitution blocks only support numeric substitutions of
numeric expressions at the moment there are plans to augment numeric
substitution blocks to support numeric definitions as well as both a
numeric definition and numeric substitution in the same numeric
substitution block.
Reviewers: jhenderson, jdenny, probinson, arichardson
Subscribers: hiraditya, arichardson, probinson, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62146
llvm-svn: 361445
Summary:
Another target that prefers to use `-march` in tests
```
llvm/test/CodeGen/SPARC$ grep -ri mtriple | wc -l
25
llvm/test/CodeGen/SPARC$ grep -ri march | wc -l
165
```
This test is being affected by a further patch,
so regenerate it to better visualize the changes
Reviewers: RKSimon, dcederman, gberry
Reviewed By: RKSimon
Subscribers: jyknight, fedor.sergeev, jrtc27, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62242
llvm-svn: 361381
r360889 added new llround builtin functions. This patch adds their
signatures for the WebAssembly backend.
It also adds wasm32 support to utils/update_llc_test_checks.py, since
that's the script other targets are using for their testcases for this
feature.
Differential Revision: https://reviews.llvm.org/D62207
llvm-svn: 361327
