Declare MVT::SimpleValueType as an int8_t sized enum. This removes 400 bytes from TargetLoweringBase and probably other places.

This required changing several places to print VT enums as strings instead of raw ints since the proper method to use to print became ambiguous. This is probably an improvement anyway.

This also appears to save ~8K from an x86 self host build of llc.

llvm-svn: 266562

  template<class T> void f(T) = delete;
  template<> void f(int); // OK.

  f(3); // OK

Implementation strategy:

When an explicit specialization of a function template, a member function template or a member function of a class template is declared, clang first implicitly instantiates the declaration of a specialization from the templated-entity being explicitly specialized (since their signatures must be the same) and then links the explicit specialization being declared as a redeclaration of the aforementioned specialization.  

The problem was that when clang 'implicitly instantiates' the initial specialization, it marks the corresponding FunctionDecl as deleted if the corresponding templated-entity was deleted, rather than waiting to see whether the explicit specialization being declared provides a non-deleted body. (The eager marking of delete has advantages during overload resolution I suppose, where we don't have to try and instantiate a definition of the function to see if it is deleted). 

The present fix entails recognizing that when clang knows that an explicit specialization is being declared (for whichever templated-entity), the prior implicit instantiation should not inherit the 'deleted' status, and so we reset it to false.

I suppose an alternative fix (amongst others) could consider creating a new context (ExplicitSpecializationDeclarationSubstitution or some such) that is checked during template-argument-deduction and final substitution, and avoid inheriting the deleted status during declaration substitution.  But while conceptually cleaner, that would be a slightly more involved change (as could be some of the other alternatives: such as avoid tagging implicit specializations as deleted, and check their primary templates for the deleted status where needed), and so I chose a different path.  Hopefully it'll prove to not be a bad choice.

llvm-svn: 266561

Shows poor codegen for AVX2

llvm-svn: 266560

llvm-svn: 266559

llvm-svn: 266558

no functional change.
ExtraLoad and WrapperKind are been used only if (OpFlags == X86II::MO_GOTPCREL).

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

llvm-svn: 266557

Since elements of most kinds of DICompositeType have back references,
most are involved in uniquing cycles.  Except via the ODR 'identifier:'
field, which doesn't care about the storage type (see r266549),
they have no hope of being uniqued.

Distinct nodes are far more efficient, so use them for most kinds of
DICompositeType definitions (i.e., when DIType::isForwardDecl is false).
The exceptions:

  - DW_TAG_array_type, since their elements never have back-references
    and they never have ODR 'identifier:' fields;

  - DW_TAG_enumeration_type when there is no ODR 'identifier:' field,
    since their elements usually don't have back-references.

This breaks the last major uniquing cycle I'm aware of in the debug info
graph.  The impact won't be enormous for C++ because references to
ODR-uniqued nodes still use string-based DITypeRefs; but this should
prevent a regression in C++ when we drop the string-based references.

This wouldn't have been reasonable until r266549, when composite types
stopped relying on being uniqued by structural equivalence to prevent
blow-ups at LTO time.

llvm-svn: 266556

Make sure lld enables ODR type uniquing for debug info when invoking
LTO, as a follow-up to LLVM r266549.

llvm-svn: 266555

llvm-svn: 266554

There's a hole in the verifier right now: if a module has no compile
units, it never checks that all the string-based DITypeRefs get
resolved.  As a result, this testcase didn't fail the verifier, even
there were references to `!"has-uuid"` instead of `!"uuid"` (the former
was a composite type's 'name:' field, the latter its 'identifier:'
field).

I'm currently working on removing string-based type refs entirely, and
this testcase started failing (because the upgrade script can't resolve
the type refs).  Rather than fixing the (about-to-be-removed) hole in
the verifier, I'm just going to fix the test so that my upgrade script
handles it.

llvm-svn: 266553

Fix a couple of places in the Verifier that call `getScope()` instead of
`getRawScope()`.  Both DIDerivedType::getScope and
DICompositeType::getScope return a DITypeRef right now (which wraps a
Metadata*) so I don't think there's currently an observable bug.  I
found this because a future commit that will change them to cast to
DIScope*.

llvm-svn: 266552

I accidentally replaced `mayBeOverridden` with `!isInterposable`.
Remove the negation and add a test case that would've caught this.

Many thanks to Håkan Hjort for spotting this!

llvm-svn: 266551

This reverts commit r266541 since it introduces a use-after-free:
  http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/11471

llvm-svn: 266550

Rather than relying on the structural equivalence of DICompositeType to
merge type definitions, use an explicit map on the LLVMContext that
LLParser and BitcodeReader consult when constructing new nodes.
Each non-forward-declaration DICompositeType with a non-empty
'identifier:' field is stored/loaded from the type map, and the first
definiton will "win".

This map is opt-in: clients that expect ODR types from different modules
to be merged must call LLVMContext::ensureDITypeMap.

  - Clients that just happen to load more than one Module in the same
    LLVMContext won't magically merge types.

  - Clients (like LTO) that want to continue to merge types based on ODR
    identifiers should opt-in immediately.

I have updated LTOCodeGenerator.cpp, the two "linking" spots in
gold-plugin.cpp, and llvm-link (unless -disable-debug-info-type-map) to
set this.

With this in place, it will be straightforward to remove the DITypeRef
concept (i.e., referencing types by their 'identifier:' string rather
than pointing at them directly).

llvm-svn: 266549

Merge members that are describing the same member of the same ODR type,
even if other bits differ.  If the file or line differ, we don't care;
if anything else differs, it's an ODR violation (and we still don't
really care).

For DISubprogram declarations, this looks at the LinkageName and Scope.
For DW_TAG_member instances of DIDerivedType, this looks at the Name and
Scope.  In both cases, we know that the Scope follows ODR rules if it
has a non-empty identifier.

llvm-svn: 266548

[Target] Reduce size of the LoadExtActions array in TargetLoweringBase by half. Saving ~18K bytes from the array.

llvm-svn: 266547

llvm-svn: 266546

[Target] Fix an assertion that should have been updated when the code below it was changed in r251033.

llvm-svn: 266545

This text is also incorrect (much like r266540).  It looks like I missed
updating some of what I moved from SourceLevelDebugging.rst in r232566.

llvm-svn: 266544

Split up the long RUN and clarify the CHECK lines:

  - Explicitly confirm there are no other subprograms inside of "A".

  - Remove checks for "bar" and "baz", which were just implicitly
    checking that there were no other subprograms inside of "A".

This prepares for adding a RUN line which links the two files in the
opposite direction.

llvm-svn: 266543

This commit has no functionality change, but it adds a configuration
point for MDNodeInfo::isEqual to allow custom uniquing of subclasses of
MDNode, minimizing the diff of a follow-up.

llvm-svn: 266542

llvm-svn: 266541

Fix descriptions of DICompositeType and DIDerivedType.

llvm-svn: 266540

llvm-svn: 266539

llvm-svn: 266538

Since the result of a mapped distinct node is known up front, it's more
efficient to map them separately from uniqued nodes.  This commit pulls
them out of the post-order traversal and stores them in a worklist to be
remapped at the top-level.

This is essentially reapplying r244181 ("ValueMapper: Rotate distinct
node remapping algorithm") to the new iterative algorithm from r265456
("ValueMapper: Rewrite Mapper::mapMetadata without recursion").

Now that the traversal logic only handles uniqued MDNodes, it's much
simpler to inline it all into MDNodeMapper::createPOT (I've killed the
MDNodeMapper::push and MDNodeMapper::tryToPop helpers and localized the
traversal worklist).

The resulting high-level algorithm for MDNodeMapper::map now looks like
this:

  - Distinct nodes are immediately mapped and added to
    MDNodeMapper::DistinctWorklist using MDNodeMapper::mapDistinctNode.

  - Uniqued nodes are mapped via MDNodeMapper::mapTopLevelUniquedNode,
    which traverses the transitive uniqued subgraph of a node to
    calculate uniqued node mappings in bulk.

      - This is a simplified version of MDNodeMapper::map from before
        this commit (originally r265456) that doesn't traverse through
        any distinct nodes.

      - Distinct nodes are added to MDNodeMapper::DistinctWorklist via
        MDNodeMapper::mapDistinctNode.

      - This uses MDNodeMapper::createPOT to fill a
        MDNodeMapper::UniquedGraph (a post-order traversal and side
        table), UniquedGraph::propagateChanges to track which uniqued
        nodes need to change, and MDNodeMapper::mapNodesInPOT to create
        the uniqued nodes.

      - Placeholders for forward references are now only needed when
        there's a uniquing cycle (a cycle of uniqued nodes unbroken by
        distinct nodes).  This is the key functionality change that
        we're reintroducing (from r244181).  As of r265456, a temporary
        forward reference might be needed for any cycle that involved
        uniqued nodes.

  - After mapping the first node appropriately, MDNodeMapper::map works
    through MDNodeMapper::DistinctWorklist.  For each distinct node, its
    operands are remapped with MDNodeMapper::mapDistinctNode and
    MDNodeMapper::mapTopLevelUniquedNode until all nodes have been
    mapped.

Sadly there's nothing observable I can test here; no real functionality
change, just a compile-time speedup from reduced malloc traffic.

llvm-svn: 266537

As a minor fixup to r266258, only track nodes that needed a placeholder
in CyclicNodes in MDNodeMapper::mapUniquedNodes.  There should be no
observable functionality change, just some local memory savings because
CyclicNodes only needs to grow to accommodate nodes that are actually
involved in cycles.  (This was the original intent of r266258, or else
the vector would have been called "ChangedNodes".)

llvm-svn: 266536

128, 256 and 512 bit implementations (some not yet supported by combineX86ShuffleChain)

llvm-svn: 266535

llvm-svn: 266534

Added additional test that peeks through bitcast to v16i8 mask

llvm-svn: 266533

Failing bot:
http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental/23112/

llvm-svn: 266532

As requested by D18441

llvm-svn: 266531

llvm-svn: 266530

llvm-svn: 266529

llvm-svn: 266528

llvm-svn: 266527

* Do script driven layout only if SECTIONS section exist.

Initial commit message:

[ELF] - Implemented basic location counter support.

This patch implements location counter support. 
It also separates assign addresses for sections to assignAddressesScript() if it scipt exists.

Main testcase is test/ELF/linkerscript-locationcounter.s, It contains some work with location counter. It is basic now.
Implemented location counter assignment and '+' operations.

Patch by myself with LOTS of comments and design suggestions from Rui Ueyama.

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

llvm-svn: 266526

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266525

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

Patch by Eugene Kosov <claprix@yandex.ru>

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266524

Summary: For Incremental LTO, we need to make sure that an old
cache entry is not used when incrementally re-linking with a new
libLTO.
Adding a global LLVM_REVISION in llvm-config.h would for to
rebuild/relink the world for every "git pull"/"svn update".
So instead only libLTO is made dependent on the VCS and will
be rebuilt (and the dependent binaries relinked, i.e. as of
today: libLTO.dylib and llvm-lto).

Reviewers: beanz

Subscribers: llvm-commits

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

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266523