It has been done in CMake build.

llvm-svn: 239989

  - Generate #include in configure.ac.
  - Resurrect the copy of llvm-config.h.cmake into config.h.cmake.

llvm-svn: 239987

FIXME: Could we unify the description of LLVM_ENABLE_ABI_BREAKING_CHECKS between *.in and *.cmake?
llvm-svn: 239986

llvm-svn: 239984

llvm-svn: 239983

- zext the value to alloc size first, then check if the value repeats
  with zero padding included. If so we can still emit a .space
- Do the checking with APInt.isSplat(8), which handles non-pow2 types
- Also handle large constants (bit width > 64)
- In a ConstantArray all elements have the same type, so it's sufficient
  to check the first constant recursively and then just compare if all
  following constants are the same by pointer compare

llvm-svn: 239977

Revert r239972 (YAML: Assign a value returned by the default constructor to the value in an optional mapping).

This change breaks clang-format tests.

llvm-svn: 239976

This commit ensures that a value that's passed into YAML's IO mapOptional method
is going to be assigned a value returned by the default constructor for that
value's type when the appropriate key is not present in the YAML mapping.

Reviewers: Duncan P. N. Exon Smith

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

llvm-svn: 239972

Added explicit sign extension for v4i16/v8i16 to v4i32/v8i32 before conversion to floats. Matches existing support for v4i8/v8i8.

Follow up to D10433

llvm-svn: 239966

Summary:
This is done by first adding two additional instructions to convert the
alloca returned address to local and convert it back to generic. Then
replace all uses of alloca instruction with the converted generic
address. Then we can rely NVPTXFavorNonGenericAddrSpace pass to combine
the generic addresscast and the corresponding Load, Store, Bitcast, GEP
Instruction together.

Patched by Xuetian Weng (xweng@google.com). 

Test Plan: test/CodeGen/NVPTX/lower-alloca.ll

Reviewers: jholewinski, jingyue

Reviewed By: jingyue

Subscribers: meheff, broune, eliben, jholewinski, llvm-commits

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

llvm-svn: 239964

MCFragment didn't really need vtables.  The majority of virtual methods were just getters and setters.

This removes the vtables and uses dispatch on the kind to do things like delete which needs to
get the appropriate class.

This reduces memory on the verify use list order test case by about 2MB out of 800MB.

Reviewed by Rafael Espíndola

llvm-svn: 239952

Re-instates r239949 without accidentally flipping the sense of UseLEA.

llvm-svn: 239950

This reverts commit r239948, tests seem to be failing.

llvm-svn: 239949

There is a one-to-one relationship between X86Subtarget and
X86FrameLowering, but every frame lowering method would previously pull
the subtarget off the MachineFunction and query some subtarget
properties.

Over time, these locals began to grow in complexity and it became
important to keep their names and meaning in sync across all of the
frame lowering methods, leading to duplication. We can eliminate that
duplication by computing them once in the constructor.

llvm-svn: 239948

llvm-svn: 239947

llvm-svn: 239946

No functional change intended.

llvm-svn: 239944

llvm-svn: 239943

llvm-svn: 239942

The personality routine currently lives in the LandingPadInst.

This isn't desirable because:
- All LandingPadInsts in the same function must have the same
  personality routine.  This means that each LandingPadInst beyond the
  first has an operand which produces no additional information.

- There is ongoing work to introduce EH IR constructs other than
  LandingPadInst.  Moving the personality routine off of any one
  particular Instruction and onto the parent function seems a lot better
  than have N different places a personality function can sneak onto an
  exceptional function.

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

llvm-svn: 239940

It's been used before to avoid infinite loops caused by separate CGP
optimizations undoing one another.  We found one more such issue
caused by r238054.  To avoid it, generalize the "InsertedTruncs"
set to any inst, and use it to avoid touching those again.

llvm-svn: 239938

llvm-svn: 239935

There is a free bit is MCSymbol and MachO needs the same information.

llvm-svn: 239933

The restriction on unnamed aliases was removed in r239921. Mostly reverts
r239590, but we keep the test.

llvm-svn: 239923

If globals can be unnamed, there is no reason for aliases to be different.

The restriction was there since the original implementation in r36435. I
can only guess it was there because of the old bison parser for the old
alias syntax.

llvm-svn: 239921

llvm-svn: 239919

[Hexagon] Adding some compare tests, fixing existing XFAILed tests, and removing mcpu=hexagonv4 since that's the minimum version anyway.

llvm-svn: 239917

llvm-svn: 239916

Tweak test cases and rename headerIndexFor -> getHeaderIndex.

llvm-svn: 239915

Directional labels can show up in symbol tables (and we have a llvm-mc test for
that). Given that, we need to make sure they are named.

With that out of the way, use setUseNamesOnTempLabels in llvm-mc so that it
too benefits from the memory saving.

llvm-svn: 239914

llvm-svn: 239913

This matches GNU as output.

llvm-svn: 239911

Reviewers: dsanders

Reviewed By: dsanders

Subscribers: llvm-commits

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

llvm-svn: 239910

llvm-svn: 239907

Summary:
This does not include support for the immediate variants of these pseudo-instructions.
Fixes llvm.org/PR20968.

Reviewers: dsanders

Reviewed By: dsanders

Subscribers: seanbruno, emaste, llvm-commits

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

llvm-svn: 239905

Summary:
Call MCSymbolRefExpr::create() with a MCSymbol* argument, not with a StringRef
of the Symbol's name, in order to avoid creating invalid temporary symbols for
relative labels (e.g. {$,.L}tmp00, {$,.L}tmp10 etc.).

Reviewers: dsanders

Reviewed By: dsanders

Subscribers: llvm-commits

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

llvm-svn: 239901

Reviewers: dsanders

Reviewed By: dsanders

Subscribers: llvm-commits

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

llvm-svn: 239899

Summary:
Previously, MCSymbolRefExpr::create() was called with a StringRef of the symbol
name, which it would then search for in the Symbols StringMap (from MCContext).

However, relative labels (which are temporary symbols) are apparently not stored
in the Symbols StringMap, so we end up creating a new {$,.L}tmp symbol
({$,.L}tmp00, {$,.L}tmp10 etc.) each time we create an MCSymbolRefExpr by
passing in the symbol name as a StringRef.

Fortunately, there is a version of MCSymbolRefExpr::create() which takes an
MCSymbol* and we already have an MCSymbol* at that point, so we can just pass
that in instead of the StringRef.

I also removed the local StringRef calls to MCSymbolRefExpr::create() from
expandMemInst(), as those cases can be handled by evaluateRelocExpr() anyway.

Reviewers: dsanders

Reviewed By: dsanders

Subscribers: llvm-commits

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

llvm-svn: 239897

Change builtin function name and signature ( add third parameter - rounding mode ).
Added tests for intrinsics.

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

llvm-svn: 239888

names for counts with the word 'Count' to make them less ambiguous.

This will be an actual error if we use unscoped enums for any of these,
and generally this seems much clearer to read.

Also, use clang-format to normalize the formatting of this code which
seems to have been needlessly odd.

No functionality changed here.

llvm-svn: 239887