137 Commits

Author SHA1 Message Date
Coelacanthus
9a8d215400 [TableGen] Use range-based for loops (NFC)
Use range-based for loops in TableGen.

Reviewed By: Paul-C-Anagnostopoulos

Differential Revision: https://reviews.llvm.org/D101994
2021-05-07 13:34:03 +08:00
Jay Foad
fdda5b21a5 [TableGen] Fix excessive compile time issue in FixedLenDecoderEmitter
This patch reduces the time taken for clang to compile the generated
disassembler for an out-of-tree target with InsnType bigger than 64 bits
from 4m30s to 48s.

D67686 did a similar thing for CodeEmitterGen.

The idea is to tweak the API of the APInt-like InsnType class so that
we don't need so many temporary InsnTypes. This takes advantage of the
rule stated in D52100 that currently "no string of bits extracted
from the encoding may exceeed 64-bits", so we can use uint64_t for some
temporaries.

D52100 goes on to say that "fields are still permitted to exceed 64-bits
so long as they aren't one contiguous string of bits". This patch breaks
that by always using a "uint64_t tmp" in the generated decodeToMCInst,
but it should be easy to fix in FilterChooser::emitBinaryParser by
choosing to use a different type of tmp based on the known total field
width.

Differential Revision: https://reviews.llvm.org/D98046
2021-03-17 09:28:50 +00:00
Kazu Hirata
2ca15ec5a6 [TableGen] Use ListSeparator (NFC) 2021-02-28 10:59:22 -08:00
Craig Topper
47244a42c7 [TableGen] Make the map in InfoByHwMode protected. NFCI
Switch some for loops to just use the begin()/end() implementations
in the InfoByHwMode struct.

Add a method to insert into the map for the one case that was
modifying the map directly.
2021-02-11 21:16:10 -08:00
Kazu Hirata
ab8cd6c8fd [llvm] Use isa instead of dyn_cast (NFC) 2021-01-29 23:23:37 -08:00
Paul C. Anagnostopoulos
bae712927d [TableGen] Add field kind to the RecordVal class.
Differential Revision: https://reviews.llvm.org/D93969
2021-01-07 09:31:27 -05:00
Kazu Hirata
201d0ba7d2 [TableGen] Use llvm::append_range (NFC) 2021-01-02 09:24:13 -08:00
Kazu Hirata
586535f9e6 [llvm] Use isa instead of dyn_cast (NFC) 2021-01-01 12:44:56 -08:00
Cameron Desrochers
783e812623 [TableGen] Fixed 64-bit filters being sliced to 32 bits in FixedLenDecoderEmitter
When using the FixedLenDecoderEmitter, llvm-tblgen emits tables with (OPC_ExtractField, OPC_ExtractFilterValue) opcode sequences to match the contiguous fixed bits of a given instruction's encoding. This encoding is represented in a 64-bit integer. However, the filter values were represented in a 32-bit integer. As such, instructions with fixed 64-bit encodings resulted in a table with an OPC_ExtractField for all 64 bits, followed by an OPC_ExtractFilterValue containing just the low 32 bits of their encoding, causing the filter never to match.

The exact point at which the slicing occurred was during the map insertion at line 630.

Differential Revision: https://reviews.llvm.org/D92423
2020-12-14 12:42:35 -05:00
Jay Foad
0cb73d61a1 [TableGen] Indentation and whitespace fixes in generated code. NFC.
Some of these were found by running clang-format over the generated
code, although that complains about far more issues than I have fixed
here.

Differential Revision: https://reviews.llvm.org/D90937
2020-11-06 16:10:57 +00:00
Simon Cook
bae1c75f0d [TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).

AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.

To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.

This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html

Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.

At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.

Differential Revision: https://reviews.llvm.org/D74338
2020-03-13 17:13:51 +00:00
Benjamin Kramer
87d13166c7 Make llvm::StringRef to std::string conversions explicit.
This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.

This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.

This doesn't actually modify StringRef yet, I'll do that in a follow-up.
2020-01-28 23:25:25 +01:00
Simon Pilgrim
5815217b6e Reduce scope of variable to silence cppcheck warning. NFC 2019-11-09 22:10:09 +00:00
James Molloy
7fff32705f [TableGen] Support encoding per-HwMode
Much like ValueTypeByHwMode/RegInfoByHwMode, this patch allows targets
to modify an instruction's encoding based on HwMode. When the
EncodingInfos field is non-empty the Inst and Size fields of the Instruction
are ignored and taken from EncodingInfos instead.

As part of this promote getHwMode() from TargetSubtargetInfo to MCSubtargetInfo.

This is NFC for all existing targets - new code is generated only if targets
use EncodingByHwMode.

llvm-svn: 372320
2019-09-19 13:39:54 +00:00
Bjorn Pettersson
22afe8331c [TableGen] Correct comments for end of namespace. NFC
Summary:
Update end-of-namespace comments generated by
tablegen emitters to fulfill the rules setup by
clang-tidy's llvm-namespace-comment checker.

Fixed a few end-of-namespace comments in the
tablegen source code as well.

Reviewers: craig.topper

Reviewed By: craig.topper

Subscribers: craig.topper, stoklund, dschuff, sbc100, jgravelle-google, aheejin, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D66396

llvm-svn: 369865
2019-08-25 10:47:30 +00:00
Jonas Devlieghere
2c693415b7 [llvm] Migrate llvm::make_unique to std::make_unique
Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances across the monorepo.

llvm-svn: 369013
2019-08-15 15:54:37 +00:00
Michael Liao
b0f9c14a99 [TableGen] Correct the shift to the proper bit width.
- Replace the previous 32-bit shift with 64-bit one matching `OpInit`.

llvm-svn: 368513
2019-08-10 16:15:06 +00:00
Daniel Sanders
91b87f212b [TableGen] Add "InitValue": Handle operands with set bit values in decoder methods
Summary:
The problem:
  When an operand had bits explicitly set to "1" (as in the InitValue.td test case attached), the decoder was ignoring those bits, and the DecoderMethod was receiving an input where the bits were still zero.

The solution:
  We added an "InitValue" variable that stores the initial value of the operand based on what bits were explicitly initialized to 1 in TableGen code. The generated decoder code then uses that initial value to initialize the "tmp" variable, then calls fieldFromInstruction to read the values for the remaining bits that were left unknown in TableGen.

This is mainly useful when there are variations of an instruction that differ based on what bits are set in the operands, since this change makes it possible to access those bits in a DecoderMethod. The DecoderMethod can use those bits to know how to handle the input.

Patch by Nicolas Guillemot

Reviewers: craig.topper, dsanders, fhahn

Reviewed By: dsanders

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D63741

llvm-svn: 368458
2019-08-09 17:30:33 +00:00
Daniel Sanders
0aa9e9e230 Re-commit r363744: [tblgen][disasm] Allow multiple encodings to disassemble to the same instruction
It seems macOS lets you have ArrayRef<const X> even though this is apparently
forbidden by the language standard (Thanks MSVC++ for the clear error message).
Removed the problematic const's to fix this.

(It also seems I'm not receiving buildbot emails anymore and I'm trying to find
 out why. In the mean time I'll be polling lab.llvm.org to hopefully see if/when
 failures occur)

llvm-svn: 363753
2019-06-18 23:34:46 +00:00
Jordan Rupprecht
5f50076bbf Revert [tblgen][disasm] Allow multiple encodings to disassemble to the same instruction
This reverts r363744 (git commit 9b2252123d1e79d2b3594097a9d9cc60072b83d9)

This breaks many buildbots, e.g. http://lab.llvm.org:8011/builders/clang-atom-d525-fedora-rel/builds/203/steps/build%20stage%201/logs/stdio

llvm-svn: 363747
2019-06-18 22:21:31 +00:00
Daniel Sanders
532a61be1c [tblgen][disasm] Allow multiple encodings to disassemble to the same instruction
Summary:
Add an AdditionalEncoding class which can be used to define additional encodings
for a given instruction. This causes the disassembler to add an additional
encoding to its matching tables that map to the specified instruction.

Usage:
  def ADD1 : Instruction {
    bits<8> Reg;
    bits<32> Inst;

    let Size = 4;
    let Inst{0-7} = Reg;
    let Inst{8-14} = 0;
    let Inst{15} = 1; // Continuation bit
    let Inst{16-31} = 0;
    ...
  }
  def : AdditionalEncoding<ADD1> {
    bits<8> Reg;
    bits<16> Inst; // You can also have bits<32> and it will still be a 16-bit encoding
    let Size = 2;
    let Inst{0-3} = 0;
    let Inst{4-7} = Reg;
    let Inst{8-15} = 0;
    ...
  }
with those definitions, llvm-mc will successfully disassemble both of these:
  0x01 0x00
  0x10 0x80 0x00 0x00
to:
  ADD1 r1

Depends on D52366

Reviewers: bogner, charukcs

Reviewed By: bogner

Subscribers: nlguillemot, nhaehnle, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D52369

llvm-svn: 363744
2019-06-18 21:56:04 +00:00
Chandler Carruth
ae65e281f3 Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636
2019-01-19 08:50:56 +00:00
Daniel Sanders
7b5a28078c [tblgen][disasm] Emit record names again when decoder conflicts occur.
And add a test for it.

llvm-svn: 350277
2019-01-03 00:14:33 +00:00
Daniel Sanders
28c46e8037 Recommit r349041: [tblgen][disasm] Separate encodings from instructions
Removed const from the ArrayRef<const EncodingAndInst> to avoid the
std::vector<const EncodingAndInst> that G++ saw

llvm-svn: 349055
2018-12-13 16:17:54 +00:00
Daniel Sanders
bf52210850 Revert r349041: [tblgen][disasm] Separate encodings from instructions
One of the GCC based bots is objecting to a vector of const EncodingAndInst's:
In file included from /usr/include/c++/8/vector:64,
                 from /export/users/atombot/llvm/clang-atom-d525-fedora-rel/llvm/utils/TableGen/CodeGenInstruction.h:22,
                 from /export/users/atombot/llvm/clang-atom-d525-fedora-rel/llvm/utils/TableGen/FixedLenDecoderEmitter.cpp:15:
/usr/include/c++/8/bits/stl_vector.h: In instantiation of 'class std::vector<const {anonymous}::EncodingAndInst, std::allocator<const {anonymous}::EncodingAndInst> >':
/export/users/atombot/llvm/clang-atom-d525-fedora-rel/llvm/utils/TableGen/FixedLenDecoderEmitter.cpp:375:32:   required from here
/usr/include/c++/8/bits/stl_vector.h:351:21: error: static assertion failed: std::vector must have a non-const, non-volatile value_type
       static_assert(is_same<typename remove_cv<_Tp>::type, _Tp>::value,
                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/c++/8/bits/stl_vector.h:354:21: error: static assertion failed: std::vector must have the same value_type as its allocator
       static_assert(is_same<typename _Alloc::value_type, _Tp>::value,
                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

llvm-svn: 349046
2018-12-13 15:14:21 +00:00
Daniel Sanders
05a85ce79b [tblgen][disasm] Separate encodings from instructions
Summary:
Separate the concept of an encoding from an instruction. This will enable
the definition of additional encodings for the same instruction which can
be used to support variable length instruction sets in the disassembler
(and potentially assembler but I'm not working towards that right now)
without causing an explosion in the number of Instruction records that
CodeGen then has to pick between.

Reviewers: bogner, charukcs

Reviewed By: bogner

Subscribers: kparzysz, llvm-commits

Differential Revision: https://reviews.llvm.org/D52366

llvm-svn: 349041
2018-12-13 14:55:57 +00:00
Daniel Sanders
a073f1f188 Fix MSVC build by correcting placement of declspec after r345056
Going by the MSVC toolchains at godbolt.org, declspec comes after the template<...>.

llvm-svn: 345059
2018-10-23 17:41:39 +00:00
Daniel Sanders
fbf4de965c [tblgen] Allow FixedLenDecoderEmitter to use APInt-like objects as InsnType
Summary:
Some targets have very long encodings and uint64_t isn't sufficient. uint128_t
isn't portable so such targets need to use an object instead.

There is one catch with this at the moment, no string of bits extracted
from the encoding may exceeed 64-bits. Fields are still permitted to
exceed 64-bits so long as they aren't one contiguous string of bits. If
this proves to be a problem then we can modify the generation of
fieldFromInstruction() calls to account for it but for now I've added an
assertion for this.

InsnType must either be integral or an APInt-like object that must:
* Have a static const max_size_in_bits equal to the number of bits in the encoding.
* be default-constructible and copy-constructible
* be constructible from a uint64_t (this is the key area the interface deviates
  from APInt since this constructor does not take the bit width)
* be constructible from an APInt (this can be private)
* be convertible to uint64_t
* Support the ~, &,, ==, !=, and |= operators with other objects of the same type
* Support shift (<<, >>) with signed and unsigned integers on the RHS
* Support put (<<) to raw_ostream&

Reviewers: bogner, charukcs

Subscribers: nhaehnle, llvm-commits

Differential Revision: https://reviews.llvm.org/D52100

llvm-svn: 345056
2018-10-23 17:23:31 +00:00
Stella Stamenova
7214eaf562 [windows] Don't inline fieldFromInstruction on Windows
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
2018-07-25 17:33:20 +00:00
Sander de Smalen
432f7965f4 [TableGen] Increase the number of supported decoder fix-ups.
The vast number of added instructions for SVE causes TableGen to fail with an assertion:

  Assertion `Delta < 65536U && "disassembler decoding table too large!"'

This patch increases the number of supported decoder fix-ups.

Reviewers: dmgreen, stoklund, petpav01

Reviewed By: dmgreen

Differential Revision: https://reviews.llvm.org/D48937

llvm-svn: 336334
2018-07-05 10:39:15 +00:00
Nicola Zaghen
9667127c14 Rename DEBUG macro to LLVM_DEBUG.
The DEBUG() macro is very generic so it might clash with other projects.
The renaming was done as follows:
- git grep -l 'DEBUG' | xargs sed -i 's/\bDEBUG\s\?(/LLVM_DEBUG(/g'
- git diff -U0 master | ../clang/tools/clang-format/clang-format-diff.py -i -p1 -style LLVM
- Manual change to APInt
- Manually chage DOCS as regex doesn't match it.

In the transition period the DEBUG() macro is still present and aliased
to the LLVM_DEBUG() one.

Differential Revision: https://reviews.llvm.org/D43624

llvm-svn: 332240
2018-05-14 12:53:11 +00:00
Nicolai Haehnle
28fce49b60 TableGen: Use DefInit::getDef() instead of the type's getRecord()
The former simply makes more sense: we want to access the data here in
the backend, not information about the type.

More importantly, removing users of RecordRecTy::getRecord() allows us
more freedom to refactor the frontend.

Change-Id: Iee8905fd22cdb9b11c42ca03246c03d8fe4dd77f
llvm-svn: 326699
2018-03-05 14:01:30 +00:00
Alexander Shaposhnikov
f216b66f0e [tablegen] Avoid creating temporary strings
If a method / function returns a StringRef but the 
variable is of type const std::string& a temporary string is
created (StringRef has a cast operator to std::string),
which is a suboptimal behavior.

Differential revision: https://reviews.llvm.org/D34994

Test plan: make check-all

llvm-svn: 307195
2017-07-05 20:14:54 +00:00
Craig Topper
78cbee780b [TableGen] Adapt more places to getValueAsString now returning a StringRef instead of a std::string.
llvm-svn: 304347
2017-05-31 21:12:46 +00:00
Matthias Braun
2bcd3146a4 TableGen: Use StringInit instead of std::string for DagInit arg names
llvm-svn: 288644
2016-12-05 06:00:46 +00:00
Matthias Braun
9e5ef1c46f TableGen: Use StringRef instead of const std::string& in return vals.
This will allow to switch to a different string storage in an upcoming
commit.

llvm-svn: 288612
2016-12-04 05:48:16 +00:00
Eugene Zelenko
78b21da28a Fix some Clang-tidy and Include What You Use warnings; other minor fixes (NFC).
This preparation to remove SetVector.h dependency on SmallSet.h.

llvm-svn: 288256
2016-11-30 17:48:10 +00:00
Justin Lebar
f5bab4e23c Switch SmallSetVector to use DenseSet when it overflows its inline space.
Summary:
SetVector already used DenseSet, but SmallSetVector used std::set.  This
leads to surprising performance differences.  Moreover, it means that
the set of key types accepted by SetVector and SmallSetVector are
quite different!

In order to make this change, we had to convert some callsites that used
SmallSetVector<std::string, N> to use SmallSetVector<CachedHashString, N>
instead.

Reviewers: timshen

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D25648

llvm-svn: 284887
2016-10-21 21:45:01 +00:00
Mehdi Amini
fb6150f41d Use StringRef in TableGen (NFC)
llvm-svn: 283273
2016-10-04 23:47:33 +00:00
David Majnemer
319d420e44 Use the range variant of find/find_if instead of unpacking begin/end
If the result of the find is only used to compare against end(), just
use is_contained instead.

No functionality change is intended.

llvm-svn: 278469
2016-08-12 03:55:06 +00:00
Matt Arsenault
c431d0b6a1 TableGen: Allow custom register operand decoder method
This is for a situation where the encoding for a register may be
different depending on the specific operand. For some instructions,
we want to apply additional restrictions beyond the encoding's
constraints.

In AMDGPU some operands are VSrc_32, using the VS_32 pseudo register
class which accept VGPRs, SGPRs, or immediates in the encoding.
Some specific instructions with the same encoding operand do not want
to allow immediates or SGPRs, but the encoding format is different
in this case than a regular VGPR_32 operand.

This allows specifying the encoding should be treated the same
without introducing yet another dummy register class.

llvm-svn: 275929
2016-07-18 23:20:46 +00:00
Davide Italiano
ed686df953 [TableGen] Remove dead code. NFCI.
llvm-svn: 274515
2016-07-04 19:21:42 +00:00
Benjamin Kramer
d415569b3b Apply most suggestions of clang-tidy's performance-unnecessary-value-param
Avoids unnecessary copies. All changes audited & pass tests with asan.
No functional change intended.

llvm-svn: 272190
2016-06-08 19:09:22 +00:00
Benjamin Kramer
a855b3205f Apply clang-tidy's misc-move-constructor-init throughout LLVM.
No functionality change intended, maybe a tiny performance improvement.

llvm-svn: 270997
2016-05-27 14:27:24 +00:00
Craig Topper
755daee3dd No need to use utostr/utohexstr when writing into a raw_ostream. NFC
llvm-svn: 259314
2016-01-31 01:55:15 +00:00
Craig Topper
a7f2a9aef5 [TableGen] Return ArrayRef instead of a std::vector reference from getInstructionsByEnumValue(). NFC
llvm-svn: 258018
2016-01-17 20:38:14 +00:00
Rafael Espindola
123f2ae05e Default SetVector to use a DenseSet.
We use to have an odd difference among MapVector and SetVector. The map
used a DenseMop, but the set used a SmallSet, which in turn uses a
std::set.

I have changed SetVector to use a DenseSet. If you were depending on the
old behaviour you can pass an explicit set type or use SmallSetVector.
The common cases for needing to do it are:

* Optimizing for small sets.
* Sets for types not supported by DenseSet.

llvm-svn: 253439
2015-11-18 06:52:18 +00:00
Nick Lewycky
aacc91f91c Fix three typos in comments; "easilly" -> "easily".
llvm-svn: 245379
2015-08-18 22:41:58 +00:00
Yaron Keren
9267630cbc Remove and forbid raw_svector_ostream::flush() calls.
After r244870 flush() will only compare two null pointers and return,
doing nothing but wasting run time. The call is not required any more
as the stream and its SmallString are always in sync.

Thanks to David Blaikie for reviewing.

llvm-svn: 244928
2015-08-13 18:12:56 +00:00
Yaron Keren
35b21efd71 Remove raw_svector_ostream::resync and users. It's no-op after r244870.
llvm-svn: 244888
2015-08-13 12:42:25 +00:00