When assembling, a .thumb_func directive is supposed to be applicable to the
next symbol definition, even if there are intervening directives. We were
racing ahead to try and find it, and this commit should fix the issue.

Patch by Gabor Ballabas

llvm-svn: 193403

llvm-svn: 193402

There's a barrier instruction so that should still be used, but most actual
atomic operations are going to need a platform decision on the correct
behaviour (either nop if single-threaded or OS-support otherwise).

rdar://problem/15287210

llvm-svn: 193399

ARM processors without ldrex/strex need to be able to make libcalls for all
atomic operations, including the newer min/max versions.

The alternative would probably be expanding these operations in terms of
cmpxchg (as x86 does always), but in the configurations where this matters
code-size tends to be paramount so the libcall is more desirable.

llvm-svn: 193398

A TableGen indeterminacy means that the reason for the failure can
vary, and Windows gets the other option.

llvm-svn: 193394

This optimization is not SSE specific so I am moving it to DAGco.
The new scalar_to_vector dag node exposed a missing pattern in the AArch64 target that I needed to add.

llvm-svn: 193393

llvm-svn: 193391

llvm-svn: 193390

llvm-cov will now be able to read program counts from the GCDA file and
output it in the same format as gcov. The program summary tag was
identified from gcov-io.h as "\0\0\0\a3".

There is currently a bug in GCOVProfiling.cpp which does not generate
the
run- or program-counting IR, so this change was tested manually by
modifying the GCDA file and comparing the gcov and llvm-cov outputs.

llvm-svn: 193389

Make sure we're predicating right based on CPU even if the triple is 'wrong'.

llvm-svn: 193382

Only use them if the subtarget has ARM mode, as these routines are implemented
as ARM code.

rdar://15302004

llvm-svn: 193381

MCStreamer: Reimplement the virtual EmitRawText as a protected member, EmitRawTextImpl, to avoid string literal ambiguities

Also improve the implementation of EmitRawText(Twine) so it doesn't
bother using the SmallString buffer if the Twine is a simple StringRef
anyway.

llvm-svn: 193378

This reverts commit r193255 and instead creates an lto_bool_t typedef
that points to bool, _Bool, or unsigned char depending on what is
available.  Only recent versions of MSVC provide a stdbool.h header.

Reviewers: rafael.espindola

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

llvm-svn: 193377

The default case at the end of the switch handles this just fine.

llvm-svn: 193374

llvm-svn: 193373

llvm-svn: 193372

llvm-svn: 193371

llvm-svn: 193370

llvm-svn: 193363

llvm-svn: 193361

llvm-svn: 193360

This may've been used at some point but the 'print' member function grew
an Indent parameter that entirely shadows this parameter.

llvm-svn: 193358

This commit changes the struct byval lowering for arm to use inline
checks for the subtarget instead of a class abstraction to represent
the differences. The class abstraction was judged to be too much
code for this task.

No intended functionality change.

llvm-svn: 193357

Patch by: Vincent Lejeune

llvm-svn: 193356

llvm-svn: 193355

This prevents us from silently accepting invalid instructions on (for example)
Cortex-M4 with just single-precision VFP support.

No tests for the extra Pat Requires because they're essentially assertions: the
affected code should have been lowered to libcalls before ISel.

rdar://problem/15302004

llvm-svn: 193354

llvm-svn: 193351

llvm-svn: 193350

Make sure we mark all loops (scalar and vector) when vectorizing,
so that we don't try to vectorize them anymore. Also, set unroll
to 1, since this is what we check for on early exit.

llvm-svn: 193349

llvm-svn: 193344

The fused multiply instructions were added in VFPv4 but are still NEON
instructions, in particular they shouldn't be available on a Cortex-M4 not
matter how floaty it is.

llvm-svn: 193342

If an alias inherits directly from InstAlias then it doesn't get any default
"Requires" values, so llvm-mc will allow it even on architectures that don't
support the underlying instruction.

This tidies up the obvious VFP and NEON cases I found.

llvm-svn: 193340

llvm-svn: 193332

The compiler-rt functions __adddf3vfp and so on exist purely to allow Thumb1
code to make use of VFP instructions by switching back to ARM mode, they make
no sense for M-class processors which don't even have an ARM mode.

Given that justification, in practice this is a platform ABI decision so the
actual check is based on that rather than CPU features.

rdar://problem/15302004

llvm-svn: 193327

llvm-svn: 193324

Without this, customers of the MCJIT were leaking memory like crazy.

It's not really clear what the *right* memory management is here, so I'm
not trying to add lots of tests or other logic, just trying to get us
back to a better baseline. I'll follow up on the original commit to
figure out the right path forward.

llvm-svn: 193323

POP instructions are aliased to the ARM LDM variants but have different syntax.
This caused two problems: we tried to access a non-existent operand to annotate
the '!', and the error message didn't make much sense.

With some vigorous hand-waving in the error message both problems can be
fixed.

llvm-svn: 193322

generated. See:

http://llvm.org/viewvc/llvm-project?view=revision&revision=193289

llvm-svn: 193321

llvm-svn: 193320

LLVM optimizers may widen accesses to packed structures that overflow the structure itself, but should be in bounds up to the alignment of the object

llvm-svn: 193317