Commit Graph

11 Commits

Author SHA1 Message Date
Simon Cook a26bd4ec16 [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
Krzysztof Parzyszek c12a5917d2 [Hexagon] Add support for Hexagon/HVX v67 ISA 2020-01-20 16:16:49 -06:00
Chandler Carruth 2946cd7010 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
Krzysztof Parzyszek 13a9cf28a1 [Hexagon] Foundation of support for Hexagon V66
llvm-svn: 348407
2018-12-05 20:18:09 +00:00
Krzysztof Parzyszek 71a7f447f6 [Hexagon] Add HasV5 predicate for compatibility with auto-generated files
llvm-svn: 348167
2018-12-03 19:05:42 +00:00
Krzysztof Parzyszek 6bfc6577f2 [Hexagon] Remove support for V4
llvm-svn: 344791
2018-10-19 17:31:11 +00:00
Krzysztof Parzyszek d8b780dcd6 [Hexagon] Remove 'T' from HasVNN predicates, NFC
Patch by Sumanth Gundapaneni.

llvm-svn: 335124
2018-06-20 13:56:09 +00:00
Krzysztof Parzyszek a8ab1b75cb [Hexagon] Add support for Hexagon V65
llvm-svn: 320404
2017-12-11 18:57:54 +00:00
Sumanth Gundapaneni 9d954c4169 [Hexagon] Update Hexagon ArchEnum and sync some downstream changes(NFC)
Differential Revision: https://reviews.llvm.org/D38850

llvm-svn: 316099
2017-10-18 17:45:22 +00:00
Krzysztof Parzyszek f9015e62fd [Hexagon] Introduce Hexagon V62
llvm-svn: 294805
2017-02-10 23:46:45 +00:00
Krzysztof Parzyszek a72fad980c [Hexagon] Replace instruction definitions with auto-generated ones
llvm-svn: 294753
2017-02-10 15:33:13 +00:00