The MemoryBuffer is created using `RequiresNullTerminator`, so we can
safely skip the `CurPtr != CurBuf.end()` check. The redundant check
causes a cppcheck report. In addition, elsewhere, including `*CurPtr ==
'#'` below, makes the null terminator assumption as well.
Close#81120
We can use `deftype` (not using `typedef` here to be consistent
with `def`, `defm`, `defset`, `defvar`, etc) to define type aliases.
Currently, only primitive types and type aliases are supported to be
the source type and `deftype` statements can only appear at the top
level.
Reviewers: fpetrogalli, Artem-B, nhaehnle, jroelofs
Reviewed By: jroelofs, nhaehnle, Artem-B
Pull Request: https://github.com/llvm/llvm-project/pull/79570
`!getdagop` expects the dag operator to be a def, and errors out if it's
not.
While that's true in most cases, when multiclasses are involved, the
late resolution of the dag operator can result in it not being a def
yet, but still have a proper type, wich is required to check against the
optional parameter Ty in `!getdagop<Ty>`.
e.g, in the following dag:
```
(!cast<TestInstruction>(TestInstructionAndPattern::NAME) foo)
```
the operator is a UnOpInit, but all we need here is to check its type.
This fixes a bug where !getdagop is used to query the dag operator that
is dependent on the multiclass, which is not yet resolved to a def. Once
the folding is performed, the field becomes a record that can be
queried.
C++20 comes with std::erase to erase a value from std::vector. This
patch renames llvm::erase_value to llvm::erase for consistency with
C++20.
We could make llvm::erase more similar to std::erase by having it
return the number of elements removed, but I'm not doing that for now
because nobody seems to care about that in our code base.
Since there are only 50 occurrences of erase_value in our code base,
this patch replaces all of them with llvm::erase and deprecates
llvm::erase_value.
enum `RecordKind` is added to indicate the kind of Record (which
can be a normal record definition, anonymous record definition,
class or multiclass).
Some arguments like `IsMC` and `IsDefm` are removed since we can
get the information from `RecordKind`.
MultiClass argument is not used any more since aa84326.
Besides, for maintainability, we should put the implementation of
qualifying name in one place (that is `QualifyName` function), so
`Scoper` is removed and we use `IsMC` to indicate that we are in a
multiclass.
The keyword is intended for debugging purpose. It prints a message to
stderr.
This patch is based on code originally written by Adam Nemet, and on the
feedback received by the reviewers in
https://reviews.llvm.org/D157492.
The !repr operator represents the content of a variable or of a record
as a string.
This patch is based on code originally written by Adam Nemet, and on the
feedback received by the reviewers in
https://reviews.llvm.org/D157492.
We add a third argument `step` to `!range` bang operator to make it
with the same semantics as `range` in Python.
`step` can be negative. `step` is 1 by default and `step` can't be
0. If `start` < `end` and `step` is negative, or `start` > `end`
and `step` is positive, the result is an empty list.
TableGen's lexer was unable to handle nested #ifndef when the outer
`#ifdef` / `#ifndef` scope is subject to skip. This was caused by returning
the canonicalized token when it should have returned the original one.
Fix#65100.
Differential Revision: https://reviews.llvm.org/D159236
Binary and decimal values were reconginzed by strtoll, which returns
error when the msb is 1, and the error was ignored, resulting to wrong
results.
This patch fixes the issue.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D157079
Wrong error message is fixed and a note of argument is printed.
Tests are added in `llvm/test/TableGen/template-args.td`.
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D156966
So that we can simplify some code and simplify the implmentation
when we want to add new features (like adding new bang operators).
Reviewed By: fpetrogalli
Differential Revision: https://reviews.llvm.org/D156502
We provide a way to specify arguments in the form of `name=value`
so that we don't have to specify all optional arguments before the
one we'd like to change. Required arguments can alse be specified
in this way.
Note that the argument can only be specified once regardless of
the way (named or positional) to specify and positional arguments
should be put before named arguments.
Reviewed By: reames
Differential Revision: https://reviews.llvm.org/D152998
The removed code assumed that we can define classes inside a multiclass,
so the name of outer multiclass is concatenated to the qualified name.
But for current TableGen grammar, we can't define classes in multiclass,
so it is unnecessary.
This commit is requested in D152998.
A new Init type ArgumentInit is added to represent arguments. We currently only support positional arguments; an upcoming change will add named argument support.
The index of argument in error message is removed.
Differential Revision: https://reviews.llvm.org/D154066
The code to resolve class/multiclass arguments are similar, we
extract them to `resolveArguments`s to simplify code.
Reviewed By: tra, reames
Differential Revision: https://reviews.llvm.org/D154065
- This patch proposes to add `!setdagarg` and `!setdagname` bang
operators to produce a new DAG node after replacing the specified
argument value/name from the given input DAG node. E.g.,
`!setdagarg((foo 1, 2), 0, "x")` produces `(foo "x", 2)` and
`!setdagname((foo 1:$a, 2:$b), 1, "c")` produces `(foo 1:$a, 2:$c)`.
Reviewed By: simon_tatham
Differential Revision: https://reviews.llvm.org/D151842
- This patch proposes to add `!getdagarg` and `!getdagname` bang
operators as the inverse operation of `!dag`. They allow us to examine
arguments of a given dag.
Reviewed By: simon_tatham
Differential Revision: https://reviews.llvm.org/D151602
In D148197, we have made `defvar` statement able to refer to class
template arguments. However, the priority of class/multiclass
template argument is higher than variables defined by `defvar`, which
is a little counterintuitive.
In this patch, we unify the priority of variables. Each pair of
braces introduces a new scope, which may contain some additional
variables like template arguments, loop iterators, etc. We can
define local variables inside this scope via `defvar` and these
variables are of higher priority than additional variables. This
means that `defvar` will shadow additional variables with the same
name. The scope can be nested, and we use the innermost variable.
This make variables defined by `defvar` prior to class/multiclass
template arguments, loop iterators, etc. The shadow rules now are:
* `V` in a record body shadows a global `V`.
* `V` in a record body shadows template argument `V`.
* `V` in template arguments shadows a global `V`.
* `V` in a `foreach` statement list shadows any `V` in surrounding record or global scopes.
Reviewed By: tra
Differential Revision: https://reviews.llvm.org/D149016
This enables indexing in `!foreach` and permutation with `list[permlist]`.
Enhancements in syntax:
- `list<int>` is applicable as a slice element.
- `list[int,]` is evaluated as not `ElemType` but `list<ElemType>`
with a single element.
Part of D145872
FIXME: I didn't apply new semantics to BitSlice.
BitsRecTy objects are uniqued based on size. If the sizes are equal, then
the BitsRecTy objects are the same objects. We can use the base class
implementation that checks for pointer equality.
We can't refer to template arguments for defvar statements in class
definitions, or it will report some errors like:
```
error: Variable not defined: 'xxx'.
```
The key point here is we used to pass nullptr to `ParseValue` in
`ParseDefvar`. As a result, we can't refer to template arguments
since `CurRec` is nullptr in `ParseIDValue`.
So we add an argument `CurRec` to `ParseDefvar` and provide it
when parsing defvar statements in class definitions.
Reviewed By: tra, simon_tatham
Differential Revision: https://reviews.llvm.org/D148197
Since `RK::Recs` is sorted by character order, anonymous defs will be
enumerated like this;
- anonymous_0
- anonymous_1
- anonymous_10
- anonymous_100
- anonymous_1000
- ...
- anonymous_99
- anonymous_990
- ...
- anonymous_999
Some records around each gap might be wrapped around along increase or
decrease of records in middle. Then output order of anonymous defs
might be changed.
Numeric sort is expected to prevent such wrap-arounds.
This can be implemented with `StringRef::compare_numeric()`.
- ...
- anonymous_99
- anonymous_100
- ...
- anonymous_999
- anonymous_1000
- ...
See also discussions in D145874.
Differential Revision: https://reviews.llvm.org/D145874
`Opt(flag, func, desc)` registers an option into `Action`.
`OptClass<EmitterC>` is also available if `EmitterC(RK).run(OS)` is capable.
`Action` is defined as `ManagedStatic<cl::opt>` to guarantee to be created
when each registration of emitter is invoked.
`llvm::TableGenMain(argv0, MainFn)` invokes `Action` instead of `MainFn`
Differential Revision: https://reviews.llvm.org/D144351
This is a follow on to D145108. This started as simply fixing the crash on an error case reported against that change, but I think this also ends up fixing the original reported issue (https://github.com/llvm/llvm-project/issues/49830) as well. More accurately, D145108 fixed the case where the cast resolves to an existing record, and this change fixes the case where the named record doesn't exist.
Differential Revision: https://reviews.llvm.org/D145711
The core part of this change is an extension to the tablegen language to allow conditional definition of records using if-statements based on !exists conditions.
The RISCV td file change is mostly to illustrate the potential use of conditional definitions. I am deliberately not maximally simplifying in this change to make merging with downstream code (or simply rebasing while this on review) easier.
Some background to make the change understandable.
TableGen does not have an if statement internally. It has if expressions - in the form of TernInitOp with IF opcode - and foreach statements. It implements an if-statement as a foreach which iterates either 0 or 1 times.
Foreach nodes are then evaluated via unrolling inside the parser. Specifically, they are evaluated, at latest, when the outermost multiclass or loop containing them reaches end of scope. The unrolled statements remain (potentially) unresolved after unrolling, but the number of iterations must be known at this point.
An !exists clause can only evaluate at final evaluation. (Specifically, forward references to definitions are allowed - up to the end of the containing scope at least.) The existing code did not set the final flag on the resolver, and thus would leave the !exists clause in an unresolved state. This would then cause an error since we don't know how many iterations on which to unroll the (synthetic) foreach loop.
I chose to only finally-evaluate the condition of the if-expression. This allows us to pick an arm at scope exit without inhibiting definitions in the arm from having self references.
Differential Revision: https://reviews.llvm.org/D145108
Use deduction guides instead of helper functions.
The only non-automatic changes have been:
1. ArrayRef(some_uint8_pointer, 0) needs to be changed into ArrayRef(some_uint8_pointer, (size_t)0) to avoid an ambiguous call with ArrayRef((uint8_t*), (uint8_t*))
2. CVSymbol sym(makeArrayRef(symStorage)); needed to be rewritten as CVSymbol sym{ArrayRef(symStorage)}; otherwise the compiler is confused and thinks we have a (bad) function prototype. There was a few similar situation across the codebase.
3. ADL doesn't seem to work the same for deduction-guides and functions, so at some point the llvm namespace must be explicitly stated.
4. The "reference mode" of makeArrayRef(ArrayRef<T> &) that acts as no-op is not supported (a constructor cannot achieve that).
Per reviewers' comment, some useless makeArrayRef have been removed in the process.
This is a follow-up to https://reviews.llvm.org/D140896 that introduced
the deduction guides.
Differential Revision: https://reviews.llvm.org/D140955
