functions in ARMBaseInfo.h so it can be used in the MC library as well.
For anything bigger than this, we may want a means to have a small support
library for shared helper functions like this. Cross that bridge when we
come to it.

llvm-svn: 114016

targets.

llvm-svn: 114015

llvm-svn: 114014

merge the common cases.

llvm-svn: 114013

if the register is a member of the SPR register class directly instead.

llvm-svn: 114012

llvm-svn: 114009

llvm-svn: 114008

between the compiler back end and the MC libraries.

llvm-svn: 114007

VFP instructions use it for loading some constants, so implement that
handling.

Not thrilled with adding a member to MCOperand, but not sure there's much of
a better option that's not pretty fragile (like putting a double in the
union instead and just assuming that's good enough). Suggestions welcome...

llvm-svn: 113996

from certain GCC's. Patch by Neil Vachharajani!

llvm-svn: 113995

llvm-svn: 113994

the API.

llvm-svn: 113993

This fixes funcargs.exp regression reported by gdb testsuite.

llvm-svn: 113992

lldb.py module.  The priorities to search for are Debug, Release, then
BuildAndIntegration.  You can always override this with a valid PYTHONPATH
environment variable before running the test driver.

For example:

$ PYTHONPATH=/Find/My/LLDB/Module/Here ./dotest.py -v .

Python runtime will try to locate the lldb.py module from
/Find/My/LLDB/Module/Here first before trying the Debug, Release, and then
BuildAndIntegration directories.

llvm-svn: 113991

This reverts commit 113814.

This patch was never intended to stay in the repository. If you are reading this
from the future, we apologize for the noise.

llvm-svn: 113990

llvm-svn: 113989

has been fixed by r113947.  But just in case it still fails, emits a prominent
message always.

llvm-svn: 113986

Recognize VLD1q64Pseudo as a stack slot load.

Reject these if they are loading or storing a subregister. The API (and
VirtRegRewriter) doesn't know how to deal with that.

llvm-svn: 113985

encountered while building llvm-gcc for arm.  This is probably the same issue
that the ppc buildbot hit. llvm::prior works on a MachineBasicBlock::iterator,
not a plain MachineInstr.

llvm-svn: 113983

been fixed.

llvm-svn: 113981

backing out following to get it back to green,
so I can investigate in peace:

svn merge -c -113840  llvm/test/CodeGen/ARM/arm-and-tst-peephole.ll
svn merge -c -113876 -c -113839 llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp

llvm-svn: 113980

forgotten in the future.

Coalesce identical cases in switch.

No functional changes intended.

llvm-svn: 113979

llvm-svn: 113978

llvm-svn: 113977

'[' is missing. Prior commits improving recovery also improved code
completion beyond the first selector, e.g., at or after the "to" in

  calculator add:x to:y

but not after "calculator". We now provide the same completions for

  calculator <CC>

that we would for

  [calculator <CC>

if "calculator" is an expression whose type is something that can
receive Objective-C messages.

This code completion works for instance and super message sends, but not
class message sends.

llvm-svn: 113976

llvm-svn: 113975

abi for clang's objective-c compilations.
(radar 8353555).

llvm-svn: 113974

llvm-svn: 113972

  super method:arg]

will now recover nicely and insert the '[' before 'super'.

llvm-svn: 113971

llvm-svn: 113970

  a getFoo]

llvm-svn: 113969

part of parser recovery. For example, given:

  a method1:arg];

we detect after parsing the expression "a" that we have the start of a
message send expression. We pretend we've seen a '[' prior to the a,
then parse the remainder as a message send. We'll then give a
diagnostic+fix-it such as:

fixit-objc-message.m:17:3: error: missing '[' at start of message
      send expression
  a method1:arg];
  ^
  [

The algorithm here is very simple, and always assumes that the open
bracket goes at the beginning of the message send. It also only works
for non-super instance message sends at this time.

llvm-svn: 113968

If dbg.declare from non-entry block is using alloca from entry block then use offset available in StaticAllocaMap to emit DBG_VALUE. Right now, this has no material impact because varible info also collected using offset table maintained in machine module info.

llvm-svn: 113967

llvm-svn: 113966

llvm-svn: 113965

Fix pointer-signext.c test case: it was relying on value names, which don't appear in the non-assert build.  Switch to using check-next as well.

llvm-svn: 113964

llvm-svn: 113963

slot.  The easiest way to do that was to bundle up the information
we care about for aggregate slots into a new structure which demands
that its creators at least consider the question.

I could probably be convinced that the ObjC 'needs GC' bit should
be rolled into this structure.
Implement generalized copy elision.  The main obstacle here is that
IR-generation must be much more careful about making sure that exactly

llvm-svn: 113962

find the hotspots in our code when indexing the DWARF. A combination of
using SmallVector to avoid collection allocations, using fixed form
sizes when possible, and optimizing the hot loops contributed to the
speedup.

llvm-svn: 113961

was the main putative user of the binding is actually maintaining its own
different binding, see http://git.ada.cx/cgi-bin/cgit.cgi/draco.git/

llvm-svn: 113960