Make all of the RecTy constructors private, and use get() factory
methods instead. Return singleton instances when it makes sense.
ListTy instance pointers are stored in the element RecTy instance.
BitsRecTy instance pointers, one per length, are stored in a static vector.
Also unique DefInit instances. A Record has a unique DefInit which
has a unique RecordRecTy instance.
This saves some 200k-300k RecTy allocations when parsing ARM.td. It
reduces TableGen's heap usage by almost 50%.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135399 91177308-0d34-0410-b5e6-96231b3b80d8
Manage Inits in a FoldingSet. This provides several benefits:
- Memory for Inits is properly managed
- Duplicate Inits are folded into Flyweights, saving memory
- It enforces const-correctness, protecting against certain classes
of bugs
The above benefits allow Inits to be used in more contexts, which in
turn provides more dynamism to TableGen. This enhanced capability
will be used by the AVX code generator to a fold common patterns
together.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@134907 91177308-0d34-0410-b5e6-96231b3b80d8
TableGen had diagnostic printers sprinkled about in a few places. Pull them
together into a single location in Error.cpp.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133568 91177308-0d34-0410-b5e6-96231b3b80d8
class A<bit a, bits<3> x, bits<3> y> {
bits<3> z;
let z = !if(a, x, y);
}
The variable z will get the value of x when 'a' is 1 and 'y' when a is '0'.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121666 91177308-0d34-0410-b5e6-96231b3b80d8
Given the pattern below as an example:
list<dag> Pattern = [(set RC:$dst, (v4f32 (shufp:src3 RC:$src1,
(mem_frag addr:$src2))))];
The right reference resolving should lead to:
list<dag> Pattern = [(set VR128:$dst, (v4f32 (shufp:src3 VR128:$src1,
(mem_frag addr:$src2))))];
But was yielding:
list<dag> Pattern = [(set VR128:$dst, (v4f32 (shufp VR128:$src1,
(mem_frag addr:$src2))))];
Fix this by passing the right name when creating a new DagInit node.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@106670 91177308-0d34-0410-b5e6-96231b3b80d8
When a target instruction wants to set target-specific flags, it should simply
set bits in the TSFlags bit vector defined in the Instruction TableGen class.
This works well because TableGen resolves member references late:
class I : Instruction {
AddrMode AM = AddrModeNone;
let TSFlags{3-0} = AM.Value;
}
let AM = AddrMode4 in
def ADD : I;
TSFlags gets the expected bits from AddrMode4 in this example.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@100384 91177308-0d34-0410-b5e6-96231b3b80d8
Remove much horribleness from X86InstrFormats as a result. Similar
simplifications are probably possible for other targets.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99539 91177308-0d34-0410-b5e6-96231b3b80d8
If a TableGen class has an initializer expression containing an X.Y subexpression,
AND X depends on template parameters,
AND those template parameters have defaults,
AND some parameters with defaults are beyond position 1,
THEN parts of the initializer expression are evaluated prematurely with the default values when the first explicit template parameter is substituted, before the remaining explicit template parameters have been substituted.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99492 91177308-0d34-0410-b5e6-96231b3b80d8
values, resolving references to them, and then removing the definitions.
If a template argument is set to an undefined value, we need to resolve
references to that argument to an explicit undefined value. The current code
leaves the reference to the template argument as it is, which causes an
assertion failure later when the definition of the template argument is
removed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@89581 91177308-0d34-0410-b5e6-96231b3b80d8
- This manifested as non-determinism in the .inc output in rare cases (when two
distinct patterns ended up being equivalent, which is rather rare). That
meant the pattern matching was non-deterministic, which could eventually mean
the code generator selected different instructions based on the arch.
- It's probably worth making the DAGISel ensure a total ordering (or force the
user to), but the simple fix here is to totally order the Record* maps based
on a unique ID.
- PR4672, PR4711.
Yay:
--
ddunbar@giles:~$ cat ~/llvm.obj.64/lib/Target/*/*.inc | shasum
d1099ff34b21459a5a3e7021c225c080e6017ece -
ddunbar@giles:~$ cat ~/llvm.obj.ppc/lib/Target/*/*.inc | shasum
d1099ff34b21459a5a3e7021c225c080e6017ece -
--
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79846 91177308-0d34-0410-b5e6-96231b3b80d8
other operators. For the rare cases where a list type cannot be
deduced, provide a []<type> syntax, where <type> is the list element
type.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73078 91177308-0d34-0410-b5e6-96231b3b80d8
Use it on dags and lists like this:
class decls {
string name;
}
def Decls : decls;
class B<list<string> names> : A<!foreach(Decls.name, names, !strconcat(Decls.name, ", Sr."))>;
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71803 91177308-0d34-0410-b5e6-96231b3b80d8
Create an OpInit class to serve as a base for all operation Inits.
Move parsing of operation constructs to separate functions and reference
from multiple places.
Add some commented out new operations. Coming soon.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71789 91177308-0d34-0410-b5e6-96231b3b80d8
If we're resolving a list element access and we're given a VarInit,
return a new VarListElementInit referencing the VarInit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71787 91177308-0d34-0410-b5e6-96231b3b80d8
