and -no-integrated-as for source with static function.

The compiler generates assembly names containing \" in the
.s dump causing gnu assembler to complain. That issue will be
investigated separately. 

llvm-svn: 254705

llvm-svn: 254704

llvm-svn: 254703

clang converts C++ lambdas to blocks with an implicit user-defined conversion
operator method on the lambda record. This method returns a block that captures a copy
of the lambda. To inline a lambda-converted block, the analyzer now calls the lambda
records's call operator method on the lambda captured by the block.

llvm-svn: 254702

cmp&swap is not well supported -- the new test
case triggers some assembler error.

This is a partial fix to the general problem (lack
of atomics operation support for certain targets).

llvm-svn: 254701

This reverts commit r254694.

It broke bootstrap.

llvm-svn: 254700

to treat as an ICE results in undefined behavior. Instead, return the "natural"
result of the operation (signed wraparound / inf / nan).

llvm-svn: 254699

"Stepping out from a.out`bar at a.c:3returning to frame"

llvm-svn: 254698

llvm-svn: 254697

llvm-svn: 254696

llvm-svn: 254695

Summary:
If we remove the MMOs from Load/Store instructions,
they are treated as volatile. This makes other optimization passes unhappy.
eg. Load/Store Optimization

So, it looks better to merge, not remove.

Reviewers: gberry, mcrosier

Subscribers: gberry, llvm-commits

Differential Revision: http://reviews.llvm.org/D14797

llvm-svn: 254694

This class is turning into a useful interface, rather than an implementation
detail, so I'm dropping the 'Base' suffix.

No functional change.

llvm-svn: 254693

llvm-svn: 254692

Mark functions and types with the appropriate visibility.  This is particularly
useful for environments which explicitly indicate origin of functions (Windows).
This aids in generating libc++abi as a DSO which exposes only the public
interfaces.

llvm-svn: 254691

Cleanup some code with clang-format to make the following change easier to
identify material difference.  NFC.

llvm-svn: 254690

Cleans up some very old code in AsmWriter's WriteConstantInternal.

llvm-svn: 254688

This reverts commit b7250858d96b8ce567681214273ac0e62713c661.

Reverting in order to investigate Windows test failure.

llvm-svn: 254687

llvm-svn: 254686

FIXME: It may be ELF-generic.
llvm-svn: 254685

with its source instead of forcing the values on GPRs.

This improves the lowering of vector code when such bitcasts happen in the
middle of vector computations.

rdar://problem/23691584 

llvm-svn: 254684

Re-comitting with a change that avoids undefined uses getting put into
the VRegUses list.

The new algorithm remembers the uses encountered while walking backwards
until a matching def is found. Contrary to the previous version this:
- Works without LiveIntervals being available
- Allows to increase the precision to subregisters/lanemasks
  (not used for now)

The changes in the AMDGPU tests are necessary because the R600 scheduler
is not stable with respect to the order of nodes in the ready queues.

Differential Revision: http://reviews.llvm.org/D9068

llvm-svn: 254683

Summary:
Looking into some recent issues with LLDBs expression parser highlighted that upstream clang passes vectors types differently to Android Open Source Project's clang for Arm Android targets.
This patch reflects the changes present in the AOSP and allows LLDB's JIT expression evaluation to work correctly for Arm Android targets when passing vectors.

This is submitted with consent of the original author Stephen Hines.

Reviewers: asl, rsmith, ADodds, rnk

Subscribers: rnk, aemerson, tberghammer, danalbert, srhines, cfe-commits, pirama

Differential Revision: http://reviews.llvm.org/D14639

llvm-svn: 254682

This is a revised version of r254655 which uses a Printable wrapper
class to avoid ambiguous overload problems.

Differential Revision: http://reviews.llvm.org/D14348

llvm-svn: 254681

Summary:
computeRegisterLiveness and analyzePhysReg are currently getting
confused about liveness in some cases, breaking copyPhysReg's
calculation of whether AX is dead in some cases. Work around this issue
temporarily by assuming that AX is always live.

See detail in: https://llvm.org/bugs/show_bug.cgi?id=25033#c7
And associated bugs PR24535 PR25033 PR24991 PR24992 PR25201.

This workaround makes the code correct but slightly inefficient, but it
seems to confuse the machine instr verifier which now things EAX was
undefined in some cases where it's being conservatively saved /
restored.

Reviewers: majnemer, sanjoy
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D15198

llvm-svn: 254680

It became impossible to get here with a half in r157393, over 3 years
ago.

llvm-svn: 254679

With the latest refactoring and code sharing patches landed, 
it is possible to unify the value profile implementation between
raw and indexed profile. This is part  in prfofile runtime.

Differential Revision: http://reviews.llvm.org/D15057

llvm-svn: 254678

With the latest refactoring and code sharing patches landed, 
it is possible to unify the value profile implementation between
raw and indexed profile. This is the patch in raw profile reader 
that uses the common interface. 

Differential Revision: http://reviews.llvm.org/D15056

llvm-svn: 254677

llvm-svn: 254676

llvm-svn: 254675

CFI emits jump slots for indirect functions as a byte array
constant, and declares function-typed aliases to these constants.

This change fixes AsmPrinter to emit these aliases as function
symbols and not data symbols.

llvm-svn: 254674

array size idiom.

llvm-svn: 254673

llvm-svn: 254672

Currently in LLVM's cost model, a vectorized arithmetic instruction will have
high cost if its type is split into multiple registers. However, this
punishment is too heavy and unnecessary. The overhead of the split should not
be on arithmetic instructions but instructions that implement the split. Note
that during vectorization we have calculated the register pressure, and we
only choose proper interleaving factor (and also vectorization factor) so
that we don't use more registers than the maximum number.

Here is a very simple example: if a vadd has the cost 1, and if we double VF
so that we need two registers to perform it, then its cost will become 4 with
the current implementation, which will prevent us to use larger VF.


Differential revision: http://reviews.llvm.org/D15159

llvm-svn: 254671

Fix calculating address of arguments larger than 32 bit on stack for
variadic functions (rounding up address to alignment) on ppc32 architecture.

Patch by Strahinja Petrovic.

Differential Revision: http://reviews.llvm.org/D14871

llvm-svn: 254670

This change adds support for an optional weight when merging profile data with the llvm-profdata tool.
Weights are specified by adding an option ':<weight>' suffix to the input file names.

Adding support for arbitrary weighting of input profile data allows for relative importance to be placed on the
input data from multiple training runs.

Both sampled and instrumented profiles are supported.

Reviewers: dnovillo, bogner, davidxl

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D14547

llvm-svn: 254669

Differential revision: http://reviews.llvm.org/D15216

llvm-svn: 254668

llvm-svn: 254667

llvm-svn: 254666

Code generation often exposes redundant physical register copies through
virtual registers such as:

  %vreg = COPY %PHYSREG
  ...
  %PHYSREG = COPY %vreg

There are cases where no intervening clobber of %PHYSREG occurs, and the
later copy could therefore be removed. In some cases this further allows
us to remove the initial copy.

This patch contains a motivating example which comes from the x86 build
of Chrome, specifically cc::ResourceProvider::UnlockForRead uses
libstdc++'s implementation of hash_map. That example has two tests live
at the same time, and after machine sinking LLVM has confused itself
enough and things spilling EFLAGS is a great idea even though it's
never restored and the comparison results are both live.

Before this patch we have:
  DEC32m %RIP, 1, %noreg, <ga:@L>, %noreg, %EFLAGS<imp-def>
  %vreg1<def> = COPY %EFLAGS; GR64:%vreg1
  %EFLAGS<def> = COPY %vreg1; GR64:%vreg1
  JNE_1 <BB#1>, %EFLAGS<imp-use>

Both copies are useless. This patch tries to eliminate the later copy in
a generic manner.

dec is especially confusing to LLVM when compared with sub.

I wrote this patch to treat all physical registers generically, but only
remove redundant copies of non-allocatable physical registers because
the allocatable ones caused issues (e.g. when calling conventions weren't
properly modeled) and should be handled later by the register allocator
anyways.

The following tests used to failed when the patch also replaced allocatable
registers:
  CodeGen/X86/StackColoring.ll
  CodeGen/X86/avx512-calling-conv.ll
  CodeGen/X86/copy-propagation.ll
  CodeGen/X86/inline-asm-fpstack.ll
  CodeGen/X86/musttail-varargs.ll
  CodeGen/X86/pop-stack-cleanup.ll
  CodeGen/X86/preserve_mostcc64.ll
  CodeGen/X86/tailcallstack64.ll
  CodeGen/X86/this-return-64.ll
This happens because COPY has other special meaning for e.g. dependency
breakage and x87 FP stack.

Note that all other backends' tests pass.

Reviewers: qcolombet
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D15157

llvm-svn: 254665