directional labels.  Because it doesn't work for windows :)

llvm-svn: 197731

llvm-svn: 197730

llvm-svn: 197729

The X86 assembler has a separate code to parser the intel assembly syntax
in X86AsmParser::ParseIntelOperand().  This did not parse directional labels.
And if something like 1f was used as a branch target it would get an
"Unexpected token" error.

The fix starts in X86AsmParser::ParseIntelExpression() in the case for
AsmToken::Integer, it needs to grab the IntVal from the current token
then look for a 'b' or 'f' following the Integer.  Then it basically needs to
do what is done in AsmParser::parsePrimaryExpr() for directional
labels.  It saves the MCExpr it creates in the IntelExprStateMachine
in the Sym field.

When it returns to X86AsmParser::ParseIntelOperand() it looks
for a non-zero Sym field in the IntelExprStateMachine and if
set it creates a memory operand not an immediate operand
it would normally do for the Integer.

rdar://14961158

llvm-svn: 197728

The main changes are in:
  include/lld/Core/Reference.h
  include/lld/ReaderWriter/Reader.h
Everything else is details to support the main change.

1) Registration based Readers
Previously, lld had a tangled interdependency with all the Readers.  It would
have been impossible to make a streamlined linker (say for a JIT) which
just supported one file format and one architecture (no yaml, no archives, etc).
The old model also required a LinkingContext to read an object file, which
would have made .o inspection tools awkward.

The new model is that there is a global Registry object. You programmatically 
register the Readers you want with the registry object. Whenever you need to 
read/parse a file, you ask the registry to do it, and the registry tries each 
registered reader.

For ease of use with the existing lld code base, there is one Registry
object inside the LinkingContext object. 


2) Changing kind value to be a tuple
Beside Readers, the registry also keeps track of the mapping for Reference
Kind values to and from strings.  Along with that, this patch also fixes
an ambiguity with the previous Reference::Kind values.  The problem was that
we wanted to reuse existing relocation type values as Reference::Kind values.
But then how can the YAML write know how to convert a value to a string? The
fix is to change the 32-bit Reference::Kind into a tuple with an 8-bit namespace
(e.g. ELF, COFFF, etc), an 8-bit architecture (e.g. x86_64, PowerPC, etc), and
a 16-bit value.  This tuple system allows conversion to and from strings with 
no ambiguities.

llvm-svn: 197727

llvm-svn: 197726

A comment following the "{" of a braced list seems to almost always
refer to the first element of the list and thus should be aligned
to it.

Before (with Cpp11 braced list style):
  SomeFunction({  // Comment 1
                   "first entry",
                   // Comment 2
                   "second entry"});
After:
  SomeFunction({// Comment 1
                "first entry",
                // Comment 2
                "second entry"});

llvm-svn: 197725

llvm-svn: 197724

llvm-svn: 197723

llvm-svn: 197722

Pruning header includes and forward references and fixing comments.

llvm-svn: 197720

llvm-svn: 197719

According to the docs, ThreadLocal<>::get() should return NULL
if no object has been set. This patch makes that the case also for non-thread
builds and adds a very basic unit test to check it.

(This was causing PR18205 because PrettyStackTraceHead didn't get zero-
initialized and we'd crash trying to read past the end of that list. We didn't
notice this so much on Linux since we'd crash after printing all the entries,
but on Mac we print into a SmallString, and would crash before printing that.)

llvm-svn: 197718

Summary:
Allow disabling checks by regex. By default, disable alpha.* checks,
that are not particularly good tested (e.g. IdempotentOperationChecker, see
http://llvm-reviews.chandlerc.com/D2427).

Fixed a bug, that would disable all analyzer checks, when using a regex more
strict, than 'clang-analyzer-', for example --checks='clang-analyzer-deadcode-'.

Added --list-checks to list all enabled checks. This is useful to test specific
values in --checks/--disable-checks.

Reviewers: djasper, klimek

Reviewed By: klimek

CC: cfe-commits, klimek

Differential Revision: http://llvm-reviews.chandlerc.com/D2444

llvm-svn: 197717

llvm-svn: 197716

No longer leaking Argument objects after calling createArgument. However, since an OwningPtr cannot live in a std::vector yet, there are some manual deletions that have a FIXME attached to them. These will go away once C++11 support is allowed.

llvm-svn: 197715

- If llvm-config fails, output an error to the user rather than allowing
  errors to cascade.
- Always get llvm-tblgen from llvm-config's bindir.

Turns out my PATH points to a really old version of LLVM; both of these
fell out of trying to make this experience nicer.

llvm-svn: 197714

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