summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp
diff options
context:
space:
mode:
authorSimon Tatham <simon.tatham@arm.com>2018-11-28 11:43:49 +0000
committerSimon Tatham <simon.tatham@arm.com>2018-11-28 11:43:49 +0000
commit34860550f2bca6c7b927eccc8dd242c4149b24ac (patch)
tree35a6af55fe6ab4dc6a7977c51e7e2c5060e7353d /llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp
parent69c61200a99d5c6b314f866de9fe2828df2a24c8 (diff)
downloadbcm5719-llvm-34860550f2bca6c7b927eccc8dd242c4149b24ac.tar.gz
bcm5719-llvm-34860550f2bca6c7b927eccc8dd242c4149b24ac.zip
[TableGen] Better error checking for TIED_TO constraints.
There are quite strong constraints on how you can use the TIED_TO constraint between MC operands, many of which are currently not checked until compiler run time. MachineVerifier enforces that operands can only be tied together in pairs (no three-way ties), and MachineInstr::tieOperands enforces that one of the tied operands must be an output operand (def) and the other must be an input operand (use). Now we check these at TableGen time, so that if you violate any of them in a new instruction definition, you find out immediately, instead of having to wait until you compile something that makes code generation hit one of those assertions. Also in this commit, all the error reports in ParseConstraint now include the name and source location of the def where the problem happened, so that if you do trigger any of these errors, it's easier to find the part of your TableGen input where you made the mistake. The trunk sources already build successfully with this additional error check, so I think no in-tree target has any of these problems. Reviewers: fhahn, lhames, nhaehnle, MatzeB Reviewed By: MatzeB Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D53815 llvm-svn: 347743
Diffstat (limited to 'llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud