llvm-svn: 114037

Since PassRegistry is currently a shared global object, it needs locking.  While it might intuitively seem
that all the setup of this class currently happens at static initialization time, this misses the fact
that some later events can cause mutation of the PassRegistrationListeners list, and thus cause race issues.

llvm-svn: 114036

llvm-svn: 114032

llvm-svn: 114030

precision)

llvm-svn: 114028

The ELF implementation now creates text, data and bss to match the gnu as
behavior.

The text streamer still has the old MachO specific behavior since
the testsuite checks that it will error when a directive is given
before a setting the current section for example.

A nice benefit is that -n is not required anymore when producing
ELF files.

llvm-svn: 114027

llvm-svn: 114026

llvm-svn: 114025

moves. Previously, the immediate was printed as the encoded integer value,
which is incorrect.

llvm-svn: 114021

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

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

This fixes funcargs.exp regression reported by gdb testsuite.

llvm-svn: 113992

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

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

llvm-svn: 113975

llvm-svn: 113972

llvm-svn: 113970

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: 113965

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

The problem was that the test for whether a compiler supports it or not was
inaccurate, but has to be accurate: LLVM_LOCAL_VISIBILITY is an optimization
and not needed for correctness, so wrongly thinking a compiler doesn't support
it is not a big deal, but LLVM_GLOBAL_VISIBILITY is for correctness, and not
an optimization: getting it wrong is fatal: it needs to be set based on a
configure test not testing the gcc version.  Since dragonegg has moved to a
different scheme, and it was the only user of LLVM_GLOBAL_VISIBILITY, just
remove this macro.

llvm-svn: 113959

wraps up r8418316

llvm-svn: 113949

for call.  Add this.

llvm-svn: 113948

even in 64-bit mode apparently.

llvm-svn: 113945

add sldt GR32, which isn't documented in the intel manual
but which gas accepts.  Part of rdar://8418316

llvm-svn: 113938

llvm-svn: 113937

llvm-svn: 113936

version because it adds a prefix and makes even less sense
than the other broken forms.  This wraps up rdar://8431422

llvm-svn: 113932

llvm-svn: 113930

rdar://8431422

llvm-svn: 113929