Stay classy (and legal) LLVM. Remove links to 3rd party SMT solver whose links may not be permanent.

llvm-svn: 197713

The condition in selects is supposed to be i1.
Make sure we are just reading the less significant bit
of the 8 bits width value to match this constraint.

<rdar://problem/15651765>

llvm-svn: 197712

This directive will write out the assembler-maintained constant
pool for the current section. These constant pools are created to
support the ldr-pseudo instruction (e.g. ldr r0, =val).

The directive can be used by the programmer to place the constant
pool in a location that can be reached by a pc-relative offset in
the ldr instruction.

llvm-svn: 197711

Type attribute do not get an AST node by default, so these statements can be removed (it's inherited automatically from TypeAttr).

llvm-svn: 197710

llvm-svn: 197709

The ldr-pseudo opcode is a convenience for loading 32-bit constants.
It is converted into a pc-relative load from a constant pool. For
example,

  ldr r0, =0x10001
  ldr r1, =bar

will generate this output in the final assembly

  ldr r0, .Ltmp0
  ldr r1, .Ltmp1
  ...
  .Ltmp0: .long 0x10001
  .Ltmp1: .long bar

Sketch of the LDR pseudo implementation:
  Keep a map from Section => ConstantPool

  When parsing ldr r0, =val
    parse val as an MCExpr
    get ConstantPool for current Section
    Label = CreateTempSymbol()
    remember val in ConstantPool at next free slot
    add operand to ldr that is MCSymbolRef of Label

  On finishParse() callback
    Write out all non-empty constant pools
    for each Entry in ConstantPool
      Emit Entry.Label
      Emit Entry.Value

Possible improvements to be added in a later patch:
  1. Does not convert load of small constants to mov
     (e.g. ldr r0, =0x1 => mov r0, 0x1)
  2. Does reuse constant pool entries for same constant

The implementation was tested for ARM, Thumb1, and Thumb2 targets on
linux and darwin.

llvm-svn: 197708

llvm-svn: 197707

This callback is invoked when the parse has finished successfuly. It
will be used to write out ARM constant pools to implement the ldr
pseudo.

llvm-svn: 197706

This change fixes the case of arithmetic shift right - do not attempt to fold that case.
This change also relaxes the conditions when attempting to fold the logical shift right and shift left cases.

No additional IR-level test cases included at this time. See http://llvm.org/bugs/show_bug.cgi?id=17827 for proofs that these are correct transformations.

llvm-svn: 197705

'section' attribute. // rdar://15450637

llvm-svn: 197704

llvm-svn: 197703

llvm-svn: 197702

llvm-svn: 197701

llvm-svn: 197700

llvm-svn: 197699

Unexpectedly, it seems that people commonly know what they were doing
when writing a comment.

Also, being more conservative about comment breaking has the advantage
of giving more flexibility. If a linebreak within the comment can
improve formatting, the author can add it (after which clang-format
won't undo it). There is no way to override clang-format's behavior if
it breaks a comment.

llvm-svn: 197698

[CMake][Standalone] Rewrite standalone build based on llvm-config. CLANG_PATH_TO_LLVM_*(s) are deprecated.

Checked on VS10(multiconfig) and some singleconfig builders.

* Assumptions

  - You should specify llvm-config as LLVM_CONFIG.
    CMake could find one in $PATH by default.

  - ENABLE_ASSERTIONS obeys LLVM's.

* Use cases

  a) With LLVM build tree

    Assume llvm-config is in your build tree.
    Everything should work as ever.

  b) With *installed* LLVM

    Assume distributions. The source tree can be optional.

    b1) The source tree is provided on the location `llvm-config --src-root`

      - Test utils, FileCheck &c., are imported and built in the new tree.
      - Gtest is built in the tree if gtest library is not found.
      - Lit is used in $(SRCROOT)/utils/lit/lit.py.

    b2) The source tree is not provided

      - clang and utilities can be built.
      - All tests, unittests and check-clang are invalidated and not built.

llvm-svn: 197697

llvm-svn: 197696

llvm-svn: 197695

Clang was already getting this right.

llvm-svn: 197694

The tests for the disassembler were adapted from the encoder tests, and for the
most part, the output from the disassembler matches that encoder-test inputs.
There are some places where more-informative mnemonics could be produced
(notably for the branch instructions), and those cases are noted in the tests
with FIXMEs.

Future work includes:

 - Generating more-informative mnemonics when possible (this may also be done
   in the printer).

 - Remove the dependence on positional "numbered" operand-to-variable mapping
   (for both encoding and decoding).

 - Internally using 64-bit instruction variants in 64-bit mode (if this turns
   out to matter).

llvm-svn: 197693

llvm-svn: 197692

Unfortunately, the PowerPC instruction definitions make heavy use of the
positional operand encoding heuristic to map operands onto bitfield variables
in the instruction definitions. Changing this to use name-based mapping is not
trivial, however, because additional infrastructure needs to be designed to
handle mapping of complex operands (with multiple suboperands) onto multiple
bitfield variables.

In the mean time, this adds support for positionally encoded operands to
FixedLenDecoderEmitter, so that we can generate a disassembler for the PowerPC
backend. To prevent an accidental reliance on this feature, and to prevent an
undesirable interaction with existing disassemblers, a backend must opt-in to
this support by setting the new decodePositionallyEncodedOperands
instruction-set bit to true.

When enabled, this iterates the variables that contribute to the instruction
encoding, just as the encoder does, and emulates the procedure the encoder uses
to map "numbered" operands to variables. The bit range for each variable is
also determined as the encoder determines them. This map is then consulted
during the decoder-generator's loop over operands to decode, allowing the
decoder to understand both position-based and name-based operand-to-variable
mappings.

As noted in the comment on the decodePositionallyEncodedOperands definition,
this support should be removed once it is no longer needed. There should be no
change to existing disassemblers.

llvm-svn: 197691

Before:
  Diag(aaaaaaaaaaaaaaaaaaaa, aaaaaaaa) << aaaaaaaaaaaaaaaaaaaaaaaaa(
                                              aaaaaaaaaaaaa);

After:
  Diag(aaaaaaaaaaaaaaaaaaaa, aaaaaaaa)
      << aaaaaaaaaaaaaaaaaaaaaaaaa(aaaaaaaaaaaaa);

llvm-svn: 197690

I am surprised I am the first one to notice this.

llvm-svn: 197689

llvm-svn: 197688

[CMake] check-clang: Append items to CLANG_TEST_DEPS rather than set. CLANG_TEST_DEPS can be set in parent scope.

llvm-svn: 197687

llvm-svn: 197686

llvm-svn: 197685

llvm-config: Don't show build tree with --obj-root for installed llvm-config. Show $(prefix) instead.

llvm-svn: 197684

llvm-config: Show build root instead of parent path in build tree with --obj-root for CMake multiconfig.

llvm-svn: 197683

llvm-svn: 197682

llvm-svn: 197681

This is more prep for adding the PowerPC disassembler. FixedLenDecoderEmitter
should recognize PointerLikeRegClass operands as register types, and generate
register-like decoding calls instead of treating them like immediates.

llvm-svn: 197680

llvm-svn: 197679

Switched code from using hasAttr followed by getAttr to simply call getAttr directly and check the resulting value.

No functional changes intended.

llvm-svn: 197678

Currently SplitBlockAndInsertIfThen requires that branch condition is an
Instruction itself, which is very inconvenient, because it is sometimes an
Operator, or even a Constant.

llvm-svn: 197677

No functional changes intended.

llvm-svn: 197676

Hosting a call to getAttr so that we don't call it multiple times for the same attribute. Also removes a hasAttr that's not required. No functional changes intended.

llvm-svn: 197675

Reviewed at http://llvm-reviews.chandlerc.com/D2425

llvm-svn: 197674