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

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

llvm-svn: 197703

llvm-svn: 197701

llvm-svn: 197699

llvm-svn: 197696

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

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

llvm-svn: 197689

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

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

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

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

llvm-svn: 197674

Rationale: going to land D2425 shortly.
I'll re-land these COFF files along with D2425 to simplify the SVN history

llvm-svn: 197673

They are failing in assertions.

llvm-svn: 197669

Although --system-libs is expected to use after --libs, it can be used alone.

  $ bin/llvm-config --ldflags
  -L/path/to/llvm/objroot/lib

  $ bin/llvm-config --libs object
  -lLLVMObject -lLLVMSupport

  $ bin/llvm-config --system-libs
    (Blank line. "all" is assumed but nothing is printed.)
  -lrt -ldl -ltinfo -lpthread -lz

  $ bin/llvm-config --ldflags --libs --system-libs object
  -L/path/to/llvm/objroot/lib
  -lLLVMObject -lLLVMSupport
  -lrt -ldl -ltinfo -lpthread -lz

It is reimplementation of r197380, and workaround for PR3347 and PR8449.

FIXME: Each LLVM component may have its dependent system libs.
llvm-svn: 197664

llvm-svn: 197663

Stray *Tests might stay after reverting.

FIXME: Could we apply this feature to clang/unittests?
FIXME: Implement this feature to CMake.
llvm-svn: 197661

Different sized address spaces should theoretically work
most of the time now, and since 64-bit add is currently
disabled, using more 32-bit pointers fixes some cases.

llvm-svn: 197659

llvm-svn: 197658

This adds support for the .inst directive.  This is an ARM specific directive to
indicate an instruction encoded as a constant expression.  The major difference
between .word, .short, or .byte and .inst is that the latter will be
disassembled as an instruction since it does not get flagged as data.

llvm-svn: 197657

It is also not clear what the value of the test was. The API is used from
existing tools and can (and is) tested with lit.

llvm-svn: 197654

[stackprotector] Use analysis from the StackProtector pass for stack layout in PEI a nd LocalStackSlot passes.

This changes the MachineFrameInfo API to use the new SSPLayoutKind information
produced by the StackProtector pass (instead of a boolean flag) and updates a
few pass dependencies (to preserve the SSP analysis).

The stack layout follows the same approach used prior to this change - i.e.,
only LargeArray stack objects will be placed near the canary and everything
else will be laid out normally.  After this change, structures containing large
arrays will also be placed near the canary - a case previously missed by the
old implementation.

Out of tree targets will need to update their usage of
MachineFrameInfo::CreateStackObject to remove the MayNeedSP argument. 

The next patch will implement the rules for sspstrong and sspreq.  The end goal
is to support ssp-strong stack layout rules.

WIP.

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

llvm-svn: 197653

llvm-svn: 197647

This matches the data in clang which was added by Jakob Stoklund Olesen in
r179596.

Thanks for erikjv on irc for pointing me to the relevant documents:
http://sparc.com/standards/64.psabi.1.35.ps.Z
page 25: Every stack frame must be 16-byte aligned.

http://sparc.com/standards/psABI3rd.pdf
page 3-10: Although the architecture requires only word alignment, software convention and the operating system require every stack frame to be doubleword aligned.

I tried to add a test, but it looks like sparc doesn't implement dynamic stack
realignment. This will be tested in clang shortly.

llvm-svn: 197646

The inalloca attribute is designed to support passing C++ objects by
value in the Microsoft C++ ABI.  It behaves the same as byval, except
that it always implies that the argument is in memory and that the bytes
are never copied.  This attribute allows the caller to take the address
of an outgoing argument's memory and execute arbitrary code to store
into it.

This patch adds basic IR support, docs, and verification.  It does not
attempt to implement any lowering or fix any possibly broken transforms.

When this patch lands, a complete description of this feature should
appear at http://llvm.org/docs/InAlloca.html .

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

llvm-svn: 197645

llvm-svn: 197642

Patch by Derek Schuff.

llvm-svn: 197640

patch r196331.

llvm-svn: 197638

ArchiveFileDescriptorTests: Fix CMake build. Each unit test is expected to have suffix "*Tests" for lit gtest runner to seek one.

llvm-svn: 197636

ArchiveFileDescriptorTests: Resurrect part of r197600, but make it invalidated, to appease buildbots.

Please revert this several hours later ;)

llvm-svn: 197635

Similar to the file summaries, the function summaries output line,
branching and call statistics. The file summaries have been moved
outside the initial loop so that all of the function summaries can be
outputted before file summaries.

Also updated test cases.

llvm-svn: 197633