llvm-svn: 181402

llvm-svn: 181371

This seemed like the cleanest way to find the test executable.  Also fix
the file mode.

llvm-svn: 180770

Handle tied sub-operands in AsmMatcherEmitter

The problem this patch addresses is the handling of register tie
constraints in AsmMatcherEmitter, where one operand is tied to a
sub-operand of another operand.  The typical scenario for this to
happen is the tie between the "write-back" register of a pre-inc
instruction, and the base register sub-operand of the memory address
operand of that instruction.

The current AsmMatcherEmitter code attempts to handle tied
operands by emitting the operand as usual first, and emitting
a CVT_Tied node when handling the second (tied) operand.  However,
this really only works correctly if the tied operand does not
have sub-operands (and isn't a sub-operand itself).  Under those
circumstances, a wrong MC operand list is generated.

In discussions with Jim Grosbach, it turned out that the MC operand
list really ought not to contain tied operands in the first place;
instead, it ought to consist of exactly those operands that are
named in the AsmString.  However, getting there requires significant
rework of (some) targets.

This patch fixes the immediate problem, and at the same time makes
one (small) step in the direction of the long-term solution, by
implementing two changes:

1. Restricts the AsmMatcherEmitter handling of tied operands to
   apply solely to simple operands (not complex operands or
   sub-operand of such).

This means that at least we don't get silently corrupt MC operand
lists as output.  However, if we do have tied sub-operands, they
would now no longer be handled at all, except for:

2. If we have an operand that does not occur in the AsmString,
   and also isn't handled as tied operand, simply emit a dummy
   MC operand (constant 0).

This works as long as target code never attempts to access
MC operands that do no not occur in the AsmString (and are
not tied simple operands), which happens to be the case for
all targets where this situation can occur (ARM and PowerPC).

[ Note that this change means that many of the ARM custom
  converters are now superfluous, since the implement the
  same "hack" now performed already by common code. ]

Longer term, we ought to fix targets to never access *any*
MC operand that does not occur in the AsmString (including
tied simple operands), and then finally completely remove
all such operands from the MC operand list.

Patch approved by Jim Grosbach.

llvm-svn: 180677

Thanks Chandler!

llvm-svn: 180592

It makes more sense to have git-svnup here than catting said file in the
documentation (where we should rather point users to this directory).
I included git-svnrevert as an additional gift to the community. I will update
the documentation in a second commit later today.

git-svnrevert takes in a git hash for a commit, looks up the svn revision for
said commit and then creates the normal git revert commit message with the one
liner message, except instead of saying

  Revert "<<<INSERT ONELINER HERE>>>"

  This reverts commit <<<INSERT GITHASH HERE>>>

It says:

  Revert "<<<INSERT ONELINER HERE>>>"

  This reverts commit r<<<INSERT SVN REVISION HERE>>>

so git hashes will not escape into our svn logs (which just look unseemly).

llvm-svn: 180587

Pattern has source location by itself. After adding a trivial method to
retrieve it, it's unnecessary to pair a source location for CHECK-NOT patterns.
One thing revised after this is the diagnostic info is more accurate by
pointing to the start of the CHECK-NOT pattern instead of the end of the
CHECK-NOT pattern. E.g. diagnostic message previously looks like

    <stdin>:1:1: error: CHECK-NOT: string occurred!
    test
    ^
    test.txt:1:16: note: CHECK-NOT: pattern specified here
    CHECK-NOT: test
                   ^

is changed to

    <stdin>:1:1: error: CHECK-NOT: string occurred!
    test
    ^
    test.txt:1:12: note: CHECK-NOT: pattern specified here
    CHECK-NOT: test
               ^

llvm-svn: 180578

llvm-svn: 180564

Super-resources and resource groups are two ways of expressing
overlapping sets of processor resources. Now we generate table entries
the same way for both so the scheduler never needs to explicitly check
for super-resources.

llvm-svn: 180162

llvm-svn: 180161

llvm-svn: 180160

variant/dialect.  Addresses a FIXME in the emitMnemonicAliases function.
Use and test case to come shortly.
rdar://13688439 and part of PR13340.

llvm-svn: 179804

llvm-svn: 179402

llvm-svn: 179401

As these two instructions in AVX extension are privileged instructions for
special purpose, it's only expected to be used in inlined assembly.

llvm-svn: 179266

llvm-svn: 179249

llvm-svn: 179248

llvm-svn: 179247

llvm-svn: 179243

llvm-svn: 178904

What was missing was were the type strong operator|.

llvm-svn: 178879

llvm-svn: 178835

llvm-svn: 178833

It had been dropped during the switch to yaml::IO. Also add a test going
from yaml2obj to llvm-readobj. It can be extended as we add more
fields/formats to yaml2obj.

llvm-svn: 178786

Looks like the gcc in http://lab.llvm.org:8011/builders/clang-x86_64-darwin11-self-mingw32/ doesn't like "not external linkage":

/Volumes/Macintosh_HD2/buildbots/clang-x86_64-darwin11-self-mingw32/llvm.src/include/llvm/Support/YAMLTraits.h: In instantiation of 'const bool llvm::yaml::has_SequenceMethodTraits<std::vector<<unnamed>::COFFYAML::Relocation, std::allocator<<unnamed>::COFFYAML::Relocation> > >::value':
/Volumes/Macintosh_HD2/buildbots/clang-x86_64-darwin11-self-mingw32/llvm.src/include/llvm/Support/YAMLTraits.h:281:   instantiated from 'llvm::yaml::has_SequenceTraits<std::vector<<unnamed>::COFFYAML::Relocation, std::allocator<<unnamed>::COFFYAML::Relocation> > >'
/Volumes/Macintosh_HD2/buildbots/clang-x86_64-darwin11-self-mingw32/llvm.src/utils/yaml2obj/yaml2obj.cpp:627:   instantiated from here
/Volumes/Macintosh_HD2/buildbots/clang-x86_64-darwin11-self-mingw32/llvm.src/include/llvm/Support/YAMLTraits.h:243: error: 'llvm::yaml::SequenceTraits<std::vector<<unnamed>::COFFYAML::Relocation, std::allocator<<unnamed>::COFFYAML::Relocation> > >::size' is not a valid template argument for type 'size_t (*)(llvm::yaml::IO&, std::vector<<unnamed>::COFFYAML::Relocation, std::allocator<<unnamed>::COFFYAML::Relocation> >&)' because function 'static size_t llvm::yaml::SequenceTraits<std::vector<<unnamed>::COFFYAML::Relocation, std::allocator<<unnamed>::COFFYAML::Relocation> > >::size(llvm::yaml::IO&, std::vector<<unnamed>::COFFYAML::Relocation, std::allocator<<unnamed>::COFFYAML::Relocation> >&)' has not external linkage

llvm-svn: 178600

The generic structs and specializations will be refactored when obj2yaml is
changed to use yaml::IO.

llvm-svn: 178593

A9 uses itinerary classes, Swift uses RW lists. This tripped some
verification when we're expanding variants. I had to refine the
verification a bit.

llvm-svn: 178357

llvm-svn: 178319

in as an argument to push_back.

llvm-svn: 178166

Allow variants to be defined only for some processors on a target.

llvm-svn: 178074

llvm-svn: 177888

This syntax is now preferred:

  def : Pat<(subc i32:$b, i32:$c), (SUBCCrr $b, $c)>;

There is no reason to repeat the types in the output pattern.

llvm-svn: 177844

This makes it possible to define instruction patterns like this:

def LDri : F3_2<3, 0b000000,
                (outs IntRegs:$dst), (ins MEMri:$addr),
                "ld [$addr], $dst",
                [(set i32:$dst, (load ADDRri:$addr))]>;
                      ~~~

llvm-svn: 177834

Just like register classes, value types can be used in two ways in
patterns:

  (sext_inreg i32:$src, i16)

In a named leaf node like i32:$src, the value type simply provides the
type of the node directly. This simplifies type inference a lot compared
to the current practice of specifiying types indirectly with register
classes.

As an unnamed leaf node, like i16 above, the value type represents
itself as an MVT::Other immediate.

llvm-svn: 177828

A register class can appear as a leaf TreePatternNode with and without a
name:

  (COPY_TO_REGCLASS GPR:$src, F8RC)

In a named leaf node like GPR:$src, the register class provides type
information for the named variable represented by the node. The TypeSet
for such a node is the set of value types that the register class can
represent.

In an unnamed leaf node like F8RC above, the register class represents
itself as a kind of immediate. Such a node has the type MVT::i32,
we'll never create a virtual register representing it.

This change makes it possible to remove the special handling of
COPY_TO_REGCLASS in CodeGenDAGPatterns.cpp.

llvm-svn: 177825

llvm-svn: 177822

To use this in conjunction with exuberant ctags to generate a single
combined tags file, run tblgen first and then
  $ ctags --append [...]

Since some identifiers have corresponding definitions in C++ code,
it can be useful (if using vim) to also use cscope, and
  :set cscopetagorder=1
so that
  :tag X
will preferentially select the tablegen symbol, while
  :cscope find g X
will always find the C++ symbol.

Patch by Kevin Schoedel!

(a couple small formatting changes courtesy of clang-format)

llvm-svn: 177682

Native Windows Python will do line ending translation by default, which
we don't want in bash scripts.  If we're not native Windows Python, then
'b' is ignored.

llvm-svn: 177602

of complex instruction operands (e.g. address modes).

Currently, if a Pat pattern creates an instruction that has a complex
operand (i.e. one that consists of multiple sub-operands at the MI
level), this operand must match a ComplexPattern DAG pattern with the
correct number of output operands.

This commit extends TableGen to alternatively allow match a complex
operands against multiple separate operands at the DAG level.

This allows using Pat patterns to match pre-increment nodes like
pre_store (which must have separate operands at the DAG level) onto
an instruction pattern that uses a multi-operand memory operand,
like the following example on PowerPC (will be committed as a
follow-on patch):

  def STWU  : DForm_1<37, (outs ptr_rc:$ea_res), (ins GPRC:$rS, memri:$dst),
                    "stwu $rS, $dst", LdStStoreUpd, []>,
                    RegConstraint<"$dst.reg = $ea_res">, NoEncode<"$ea_res">;

  def : Pat<(pre_store GPRC:$rS, ptr_rc:$ptrreg, iaddroff:$ptroff),
            (STWU GPRC:$rS, iaddroff:$ptroff, ptr_rc:$ptrreg)>;

Here, the pair of "ptroff" and "ptrreg" operands is matched onto the
complex operand "dst" of class "memri" in the "STWU" instruction.

Approved by Jakob Stoklund Olesen.

llvm-svn: 177428

Properly handle cases where a group of instructions have different
SchedRW lists with the same itinerary class.
This was supposed to work, but I left in an early break.

llvm-svn: 177317