Commit Graph

178 Commits

Author SHA1 Message Date
Vedant Kumar
74ae925619 [tablegen] Delete duplicates from a vector without skipping elements
Tablegen's -gen-instr-info pass has a bug in its emitEnums() routine.
The function intends for values in a vector to be deduplicated, but it
accidentally skips over elements after performing a deletion.

I think there are smarter ways of doing this deduplication, but we can
do that in a follow-up commit if there's interest. See the thread:
[PATCH] TableGen InstrMapping Bug fix.

Patch by Tyler Kenney!

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288408 91177308-0d34-0410-b5e6-96231b3b80d8
2016-12-01 19:38:50 +00:00
Matt Arsenault
ee23318db7 TableGen: Add operator !or
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@286936 91177308-0d34-0410-b5e6-96231b3b80d8
2016-11-15 06:49:28 +00:00
Sam Kolton
e3aa0d989e [TableGen] AsmMatcher: Add AsmVariantName to Instruction class.
Summary:
This allows specifying instructions that are available only in specific assembler variant. If AsmVariantName is specified then instruction will be presented only in MatchTable for this variant. If not specified then assembler variants will be determined based on AsmString.
Also this allows splitting assembler match tables in same way as it is done in dissasembler.

Reviewers: ab, tstellarAMD, craig.topper, vpykhtin

Subscribers: wdng

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280952 91177308-0d34-0410-b5e6-96231b3b80d8
2016-09-08 15:50:52 +00:00
Tim Northover
415b2015a4 tests: accept different TargetOpcode values.
These tests don't actually care about the internal opcode number, but have to
be updated whenever we add a new one for GlobalISel. That's bad.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@274774 91177308-0d34-0410-b5e6-96231b3b80d8
2016-07-07 17:51:42 +00:00
Quentin Colombet
4a3ecf8a53 [Target] Introduce a generic opcode for bitwise OR: G_OR.
This G_OR is used in GlobalISel to represent bitwise OR.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272160 91177308-0d34-0410-b5e6-96231b3b80d8
2016-06-08 16:12:19 +00:00
Sanjoy Das
151328540e Introduce a "patchable-function" function attribute
Summary:
The `"patchable-function"` attribute can be used by an LLVM client to
influence LLVM's code generation in ways that makes the generated code
easily patchable at runtime (for instance, to redirect control).
Right now only one patchability scheme is supported,
`"prologue-short-redirect"`, but this can be expanded in the future.

Reviewers: joker.eph, rnk, echristo, dberris

Subscribers: joker.eph, echristo, mcrosier, llvm-commits

Differential Revision: http://reviews.llvm.org/D19046

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@266715 91177308-0d34-0410-b5e6-96231b3b80d8
2016-04-19 05:24:47 +00:00
Craig Topper
ca89139c6d Declare MVT::SimpleValueType as an int8_t sized enum. This removes 400 bytes from TargetLoweringBase and probably other places.
This required changing several places to print VT enums as strings instead of raw ints since the proper method to use to print became ambiguous. This is probably an improvement anyway.

This also appears to save ~8K from an x86 self host build of llc.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@266562 91177308-0d34-0410-b5e6-96231b3b80d8
2016-04-17 17:37:33 +00:00
Quentin Colombet
132c140240 [GlobalISel][Target] Add an opcode for unconditional branch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263259 91177308-0d34-0410-b5e6-96231b3b80d8
2016-03-11 17:27:38 +00:00
Matt Arsenault
b9f1dbe18d SelectionDAG: Make Properties a field of SDPatternOperator
Currently you can't specify node properties like commutativity on
a PatFrag. If you want to create a PatFrag on a commutative node
with a hasOneUse predicate, this enables you to specify that the
PatFrag is also commutable.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@260404 91177308-0d34-0410-b5e6-96231b3b80d8
2016-02-10 18:40:04 +00:00
Reid Kleckner
80814c51f4 [llvm-tblgen] Stop emitting the intrinsic name matching code
The AMDGPU backend was the last user of the old StringMatcher
recognition code. Move it over to the new lookupLLVMIntrinsicName
funciton, which is now improved to handle all of the interesting edge
cases exposed by AMDGPU intrinsic names.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@258875 91177308-0d34-0410-b5e6-96231b3b80d8
2016-01-26 23:01:21 +00:00
Quentin Colombet
8a7d012332 [GlobalISel] Add a generic machine opcode for ADD.
The selection process being split into separate passes, we need generic opcodes
to translate the LLVM IR to target independent code.

This patch adds an opcode for addition: G_ADD.

Differential Revision: http://reviews.llvm.org/D15472


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@258333 91177308-0d34-0410-b5e6-96231b3b80d8
2016-01-20 19:14:55 +00:00
Craig Topper
b3379c35bd Add test cases that will show the bug that was fixed in r256725.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@257584 91177308-0d34-0410-b5e6-96231b3b80d8
2016-01-13 07:53:11 +00:00
Krzysztof Parzyszek
ed5c8866a9 Add new vector types for 512-, 1024- and 2048-bit vectors
Those types are needed to implement instructions for Hexagon Vector
Extensions (HVX): 16x32, 16x64, 32x16, 32x32, 32x64, 64x8, 64x16,
64x32, 128x8, 128x16, 256x8, 512x1, and 1024x1.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@253978 91177308-0d34-0410-b5e6-96231b3b80d8
2015-11-24 13:07:35 +00:00
Krzysztof Parzyszek
85354d4e30 Revert r253923.
Per Eric's request.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@253928 91177308-0d34-0410-b5e6-96231b3b80d8
2015-11-23 22:19:57 +00:00
Krzysztof Parzyszek
277704eaac Add new vector types for 512-, 1024- and 2048-bit vectors
Those types are needed to implement instructions for Hexagon Vector
Extensions (HVX): 16x32, 16x64, 32x16, 32x32, 32x64, 64x8, 64x16,
64x32, 128x8, 128x16, 256x8, 512x1, and 1024x1.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@253923 91177308-0d34-0410-b5e6-96231b3b80d8
2015-11-23 22:00:17 +00:00
Joseph Tremoulet
16c6479624 [TableGen] Allow TokenTy in intrinsic signatures
Summary:
Add the necessary plumbing so that llvm_token_ty can be used as an
argument/return type in intrinsic definitions and correspondingly require
TokenTy in function types.  TokenTy is an opaque type that has no target
lowering, but can be used in machine-independent intrinsics.  It is
required for the upcoming llvm.eh.padparam intrinsic.

Reviewers: majnemer, rnk

Subscribers: stoklund, llvm-commits

Differential Revision: http://reviews.llvm.org/D12532

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246651 91177308-0d34-0410-b5e6-96231b3b80d8
2015-09-02 13:36:25 +00:00
Matt Arsenault
6a224c30a5 TableGen: Support folding casts from bits to int
This is to fix an incorrect error when trying to initialize
DwarfNumbers with a !cast<int> of a bits initializer.
getValuesAsListOfInts("DwarfNumbers") would not see an IntInit
and instead the cast, so would give up.

It seems likely that this could be generalized to attempt
the convertInitializerTo for any type. I'm not really sure
why the existing code seems to special case the string cast cases
when convertInitializerTo seems like it should generally handle this
sort of thing.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243722 91177308-0d34-0410-b5e6-96231b3b80d8
2015-07-31 01:12:06 +00:00
Petr Pavlu
d2e1e42c1a [TableGen] Improve decoding options for non-orthogonal instructions
When FixedLenDecoder matches an input bitpattern of form [01]+ with an
instruction bitpattern of form [01?]+ (where 0/1 are static bits and ? are
mixed/variable bits) it passes the input bitpattern to a specific instruction
decoder method which then makes a final decision whether the bitpattern is a
valid instruction or not. This means the decoder must handle all possible
values of the variable bits which sometimes leads to opcode rewrites in the
decoder method when the instructions are not fully orthogonal.

The patch provides a way for the decoder method to say that when it returns
Fail it does not necessarily mean the bitpattern is invalid, but rather that
the bitpattern is definitely not an instruction that is recognized by the
decoder method. The decoder can then try to match the input bitpattern with
other possible instruction bitpatterns.

For example, this allows to solve a situation on AArch64 where the `MSR
(immediate)` instruction has form:
1101 0101 0000 0??? 0100 ???? ???1 1111
but not all values of the ? bits are allowed. The rejected values should be
handled by the `extended MSR (register)` instruction:
1101 0101 000? ???? ???? ???? ???? ????

The decoder will first try to decode an input bitpattern that matches both
bitpatterns as `MSR (immediate)` but currently this puts the decoder method of
`MSR (immediate)` into a situation when it must be able to decode all possible
values of the ? bits, i.e. it would need to rewrite the instruction to `MSR
(register)` when it is not `MSR (immediate)`.

The patch allows to specify that the decoder method cannot determine if the
instruction is valid for all variable values. The decoder method can simply
return Fail when it knows it is definitely not `MSR (immediate)`. The decoder
will then backtrack the decoding and find that it can match the input
bitpattern with the more generic `MSR (register)` bitpattern too.

Differential Revision: http://reviews.llvm.org/D7174


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@242274 91177308-0d34-0410-b5e6-96231b3b80d8
2015-07-15 08:04:27 +00:00
Michael Kuperstein
d714fcf5c8 Use std::bitset for SubtargetFeatures.
Previously, subtarget features were a bitfield with the underlying type being uint64_t. 
Since several targets (X86 and ARM, in particular) have hit or were very close to hitting this bound, switching the features to use a bitset.
No functional change.

The first several times this was committed (e.g. r229831, r233055), it caused several buildbot failures.
Apparently the reason for most failures was both clang and gcc's inability to deal with large numbers (> 10K) of bitset constructor calls in tablegen-generated initializers of instruction info tables. 
This should now be fixed.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@238192 91177308-0d34-0410-b5e6-96231b3b80d8
2015-05-26 10:47:10 +00:00
Hal Finkel
80bb2d981d [TableGen] Resolve complex def names inside multiclasses
We had not been trying hard enough to resolve def names inside multiclasses
that had complex concatenations, etc. Now we'll try harder.

Patch by Amaury Sechet!

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@237877 91177308-0d34-0410-b5e6-96231b3b80d8
2015-05-21 04:32:56 +00:00
Michael Kuperstein
66112dd7f8 Reverting r237234, "Use std::bitset for SubtargetFeatures"
The buildbots are still not satisfied.
MIPS and ARM are failing (even though at least MIPS was expected to pass).


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@237245 91177308-0d34-0410-b5e6-96231b3b80d8
2015-05-13 10:28:46 +00:00
Michael Kuperstein
1336daad86 Use std::bitset for SubtargetFeatures
Previously, subtarget features were a bitfield with the underlying type being uint64_t. 
Since several targets (X86 and ARM, in particular) have hit or were very close to hitting this bound, switching the features to use a bitset.
No functional change.

The first two times this was committed (r229831, r233055), it caused several buildbot failures. 
At least some of the ARM and MIPS ones were due to gcc/binutils issues, and should now be fixed.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@237234 91177308-0d34-0410-b5e6-96231b3b80d8
2015-05-13 08:27:08 +00:00
Kit Barton
1e3da044d8 Add support for v1i128 type.
The v1i128 type is needed for the quadword add/substract instructions introduced
in POWER8. Futhermore, the PowerPC ABI specifies that parameters of type v1i128
are to be passed in a single vector register, while parameters of type i128 are
passed in pairs of GPRs. Thus, it is necessary to be able to differentiate
between v1i128 and i128 in LLVM.

http://reviews.llvm.org/D8564


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235198 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-17 16:11:05 +00:00
Toma Tabacu
0e407e7bbf [TableGen] Prevent invalid code generation when emitting AssemblerPredicate conditions.
Summary:
The loop which emits AssemblerPredicate conditions also links them together by emitting a '&&'.
If the 1st predicate is not an AssemblerPredicate, while the 2nd one is, nothing gets emitted for the 1st one, but we still emit the '&&' because of the 2nd predicate.
This generated code looks like "( && Cond2)" and is invalid.

Reviewers: dsanders

Reviewed By: dsanders

Subscribers: dsanders, llvm-commits

Differential Revision: http://reviews.llvm.org/D8294

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234312 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-07 12:10:11 +00:00
Robert Khasanov
cfa5724d50 [AVX512] Added intrinsics for VPCMPEQB and VPCMPEQW.
Added new operand type for intrinsics (IIT_V64)


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218668 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-30 11:32:22 +00:00
Craig Topper
00666192c1 Update test case to match minor formatting change introduced in r218563.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218564 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-27 05:36:53 +00:00
Craig Topper
00bc445d75 Fix TableGen -gen-disassembler output for bit fields with an offset.
This fixes bit assignments like this
Inst{7-0} = Foo{9-2}

Patch by Steve King.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218560 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-27 04:38:02 +00:00
Adam Nemet
763d8b2ef7 [TableGen] Fully resolve class-instance values before defs in multiclasses
By class-instance values I mean 'Class<Arg>' in 'Class<Arg>.Field' or in
'Other<Class<Arg>>' (syntactically s SimpleValue).  This is to differentiate
from unnamed/anonymous record definitions (syntactically an ObjectBody) which
are not affected by this change.

Consider the testcase:

    class Struct<int i> {
      int I = !shl(i, 1);
      int J = !shl(I, 1);
    }

    class Class<Struct s> {
        int Class_J = s.J;
    }

    multiclass MultiClass<int i> {
      def Def : Class<Struct<i>>;
    }

    defm Defm : MultiClass<2>;

Before this fix, DefmDef.Class_J yields !shl(I, 1) instead of 8.

This is the sequence of events.  We start with this:

    multiclass MultiClass<int i> {
      def Def : Class<Struct<i>>;
    }

During ParseDef the anonymous object for the class-instance value is created:

    multiclass Multiclass<int i> {
      def anonymous_0 : Struct<i>;

      def Def : Class<NAME#anonymous_0>;
    }

Then class Struct<i> is added to anonymous_0.  Also Class<NAME#anonymous_0> is
added to Def:

    multiclass Multiclass<int i> {
      def anonymous_0 {
        int I = !shl(i, 1);
        int J = !shl(I, 1);
      }

      def Def {
        int Class_J = NAME#anonymous_0.J;
      }
    }

So far so good but then we move on to instantiating this in the defm
by substituting the template arg 'i'.

This is how the anonymous prototype looks after fully instantiating.

    defm Defm = {
      def Defmanonymous_0 {
         int I = 4;
         int J = !shl(I, 1);
      }

Note that we only resolved the reference to the template arg.  The
non-template-arg reference in 'J' has not been resolved yet.

Then we go on to instantiating the Def prototype:

      def DefmDef {
         int Class_J = NAME#anonymous_0.J;
      }

Which is resolved to Defmanonymous_0.J and then to !shl(I, 1).

When we fully resolve each record in a defm, Defmanonymous_0.J does get set
to 8 but that's too late for its use.

The patch adds a new attribute to the Record class that indicates that this
def is actually a class-instance value that may be *used* by other defs in a
multiclass.  (This is unlike regular defs which don't reference each other and
thus can be resolved indepedently.)  They are then fully resolved before the
other defs while the multiclass is instantiated.

I added vg_leak to the new test.  I am not sure if this is necessary but I
don't think I have a way to test it.  I can also check in without the XFAIL
and let the bots test this part.

Also tested that X86.td.expanded and AAarch64.td.expanded were unchange before
and after this change.  (This issue triggering this problem is a WIP patch.)

Part of <rdar://problem/17688758>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217886 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-16 17:14:13 +00:00
Jean-Luc Duprat
1da4862939 Tablegen fixes for new syntax when initializing bits from variables.
Followup to r215086.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216757 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-29 19:41:04 +00:00
NAKAMURA Takumi
87d7e906ce llvm/test/TableGen/*Foreach*.td: Remove XFAIL:vg_leak. They have not been failing since r215176.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215445 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-12 14:06:21 +00:00
Pete Cooper
ecdbbbefea Update BitRecTy::convertValue to allow if expressions with bit values on both sides of the if
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215087 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-07 05:47:10 +00:00
Pete Cooper
64a334da36 Change the { } expression in tablegen to accept sized binary literals which are not just 0 and 1.
It also allows nested { } expressions, as now that they are sized, we can merge pull bits from the nested value.

In the current behaviour, everything in { } must have been convertible to a single bit.
However, now that binary literals are sized, its useful to be able to initialize a range of bits.

So, for example, its now possible to do

bits<8> x = { 0, 1, { 0b1001 }, 0, 0b0 }

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215086 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-07 05:47:07 +00:00
Pete Cooper
2093e2cb43 Change BitsInit to inherit from TypedInit.
This is useful in a later patch where binary literals such as 0b000 will become BitsInit values instead of IntInit values.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215085 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-07 05:47:04 +00:00
Pete Cooper
42c1227fd9 Change TableGen so that binary literals such as 0b001 are now sized.
Instead of these becoming an integer literal internally, they now become bits<n> values.

Prior to this change, 0b001 was 1 bit long.  This is confusing as clearly the user gave 3 bits.
This new type holds both the literal value and the size, and so can ensure sizes match on initializers.

For example, this used to be legal

bits<1> x = 0b00;

but now it must be written as

bits<2> x = 0b00;

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215084 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-07 05:47:00 +00:00
Pete Cooper
f5b7351124 TableGen: Change { } to only accept bits<n> entries when n == 1.
Prior to this change, it was legal to do something like

  bits<2> opc = { 0, 1 };
  bits<2> opc2 = { 1, 0 };
  bits<2> a = { opc, opc2 };

This involved silently dropping bits from opc and opc2 which is very hard to debug.

Now the above test would be an error.  Having tested with an assert, none of LLVM/clang was relying on this behaviour.

Thanks to Adam Nemet for the above test.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215083 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-07 05:46:57 +00:00
Joerg Sonnenberger
c754b579ae Allow binary and for tblgen math.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214851 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-05 09:43:25 +00:00
Richard Smith
434f0e3548 Revert of r213521. This change introduced a non-hermetic test (depending on a
file not in the test/ area). Backing out now so that this test isn't part of
the 3.5 branch.

Original commit message: "TableGen: Allow AddedComplexity values to be negative
[...]"


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213596 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-22 02:32:12 +00:00
Tom Stellard
4950ae5960 TableGen: Allow AddedComplexity values to be negative
This is useful for cases when stand-alone patterns are preferred to the
patterns included in the instruction definitions.  Instead of requiring
that stand-alone patterns set a larger AddedComplexity value, which
can be confusing to new developers, the allows us to reduce the
complexity of the included patterns to achieve the same result.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213521 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-21 13:28:54 +00:00
Adam Nemet
30cced119b [TableGen] Allow shift operators to take bits<n>
Convert the operand to int if possible, i.e. if the value is properly
initialized.  (I suppose there is further room for improvement here to also
peform the shift if the uninitialized bits are shifted out.)

With this little change we can now compute the scaling factor for compressed
displacement with pure tablegen code in the X86 backend.  This is useful
because both the X86-disassembler-specific part of tablegen and the assembler
need this and TD is the natural sharing place.

The patch also adds the missing documentation for the shift and add operator.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213277 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-17 17:04:27 +00:00
Justin Holewinski
df50f4150b [TABLEGEN] Do not crash on intrinsics with names longer than 40 characters
Differential Revision: http://reviews.llvm.org/D4537

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213253 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-17 11:23:29 +00:00
Matt Arsenault
258e8223e6 Fix error in tablegen when either operand of !if is an empty list.
!if([Something], []) would error with "No type for list".

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210572 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-10 20:10:08 +00:00
Artyom Skrobov
2093e88d67 Anonymous definitions in foreach blocks triggered a 'def already exists'
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210526 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-10 12:41:14 +00:00
NAKAMURA Takumi
ad4480cf8b test/TableGen: Remove XFAIL:vg_leak out of 3 tests corresponding to r208293.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208393 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-09 08:18:33 +00:00
NAKAMURA Takumi
cb64c55ba4 Mark test/TableGen/listconcat.td as XFAIL:vg_leak. llvm-tblgen is ignorant of vg_leak.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208337 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-08 17:06:10 +00:00
Daniel Sanders
d80222a48b [tablegen] Add !listconcat operator with the similar semantics as !strconcat
Summary:
It concatenates two or more lists. In addition to the !strconcat semantics
the lists must have the same element type.

My overall aim is to make it easy to append to Instruction.Predicates
rather than override it. This can be done by concatenating lists passed as
arguments, or by concatenating lists passed in additional fields.

Reviewers: dsanders

Reviewed By: dsanders

Subscribers: hfinkel, llvm-commits

Differential Revision: http://reviews.llvm.org/D3506

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208183 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-07 10:13:19 +00:00
Daniel Sanders
1913eeb385 [tablegen] !strconcat accepts more than two arguments but this wasn't documented or tested.
Summary:
* Updated the documentation
* Added a test for >2 arguments
* Added a check for the lexical concatenation
* Made the existing test a bit stricter.

Reviewers: t.p.northover

Reviewed By: t.p.northover

Subscribers: t.p.northover, llvm-commits

Differential Revision: http://reviews.llvm.org/D3485

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207865 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-02 19:25:52 +00:00
Hal Finkel
0a3368cde5 [TableGen] Correctly generate implicit anonymous prototype defs in multiclasses
Even within a multiclass, we had been generating concrete implicit anonymous
defs when parsing values (generally in value lists). This behavior was
incorrect, and led to errors when multiclass parameters were used in the
parameter list of the implicit anonymous def.

If we had some multiclass:

multiclass mc<string n> {

 ... : SomeClass<SomeOtherClass<n> >

The capture of the multiclass parameter 'n' would not work correctly, and
depending on how the implicit SomeOtherClass was used, either TableGen would
ignore something it shouldn't, or would crash.

To fix this problem, when inside a multiclass, we generate prototype anonymous
defs for implicit anonymous defs (just as we do for explicit anonymous defs).
Within the multiclass, the current record prototype is populated with a node
that is essentially: !cast<SomeOtherClass>(!strconcat(NAME, anon_value_name)).
This is then resolved to the correct concrete anonymous def, in the usual way,
when NAME is resolved during multiclass instantiation.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198348 91177308-0d34-0410-b5e6-96231b3b80d8
2014-01-02 20:47:09 +00:00
Hal Finkel
2370e55a53 [TableGen] Use the same anonymous name as the prefix on all multiclass defs
TableGen had been generating a different name for an anonymous multiclass's
NAME for every def in the multiclass. This had an unfortunate side effect: it
was impossible to reference one def within the multiclass from another (in the
parameter list, for example). By making sure we only generate an anonymous name
once per multiclass (which, as it turns out, requires only changing the name
parameter to reference type), we can now concatenate NAME within the multiclass
with a def name in order to generate a reference to that def.

This does not matter so much, in and of itself, but is necessary for a
follow-up commit that will fix variable capturing in implicit anonymous
multiclass defs (and that is important).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198340 91177308-0d34-0410-b5e6-96231b3b80d8
2014-01-02 19:35:33 +00:00
Alp Toker
4b5724b864 FileCheckize r197869
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197872 91177308-0d34-0410-b5e6-96231b3b80d8
2013-12-22 03:43:58 +00:00
Alp Toker
68545899c7 Relax tab check into a whitespace check to fix the test in r197869
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197870 91177308-0d34-0410-b5e6-96231b3b80d8
2013-12-21 19:11:31 +00:00