Patch by David Abdurachmanov!

llvm-svn: 305123

It caused `Index/availability.c` test failure on Linux

llvm-svn: 305122

llvm-svn: 305121

Currently, we load all template specialization if we have more than one module
attached and we touch anything around the template definition.

This patch registers the template specializations as lazily-loadable entities.
In some TUs it reduces the amount of deserializations by 1%.

llvm-svn: 305120

[Support] Fix some Clang-tidy modernize-use-using and Include What You Use warnings; other minor fixes (NFC).

llvm-svn: 305119

n the current local-submodule-visibility mode, as soon as we discover a virtual
destructor, we declare on demand a global delete operator. However, this causes
that this delete operator is owned by the submodule which contains said virtual
destructor. This means that other modules no longer can see the global delete
operator which is hidden inside another submodule and fail to compile.

This patch unhides those global allocation function once they're created to
prevent this issue.

Patch by Raphael Isemann (D33366)!

llvm-svn: 305118

availability

Patch by Ronald Wampler!

Differential Revision: https://reviews.llvm.org/D33478

llvm-svn: 305117

If specified, when preprocessing, the contents of imported .pcm files will be
included in preprocessed output. The resulting preprocessed file can then be
compiled standalone without the module sources or .pcm files.

llvm-svn: 305116

llvm-svn: 305115

Previously it was non-const reference named Result which would tend to make someone think that it was an outparam when really its an input.

llvm-svn: 305114

llvm-svn: 305113

llvm-svn: 305112

llvm-svn: 305111

Recommit r304592 that was reverted in r304618.  r305104 should have fixed the
issue.

llvm-svn: 305110

llvm-svn: 305109

llvm-svn: 305108

Currently there is a bug in SROA::presplitLoadsAndStores which causes assertion in
GEPOperator::accumulateConstantOffset.

Basically it does not consider the situation that the pointer operand of load or store
may be in a non-zero address space and its size may be different from the size of
a pointer in address space 0.

This patch fixes assertion when compiling Blender Cycles kernels for amdgpu backend.

Diffferential Revision: https://reviews.llvm.org/D33298

llvm-svn: 305107

This is to reflect the evolving nature of the tool as being
useful for more than just dumping PDBs, as it can do many other
things.

Differential Revision: https://reviews.llvm.org/D34062

llvm-svn: 305106

Summary:
This prevents the iterator overrides from being selected in
the case where non-iterator types are used as arguments, which
is of particular importance in cases where other overrides with
identical types exist.

Reviewers: dblaikie, bkramer, rafael

Subscribers: llvm-commits, efriedma

Differential Revision: https://reviews.llvm.org/D33919

llvm-svn: 305105

Speculatively try to fix the underlying issue from r304592, of underlying types
being confused when inline namespaces are used.

llvm-svn: 305104

llvm-svn: 305103

Summary:
isSafeToSpeculativelyExecute is the wrong predicate to use here.
All that checks for is whether it is safe to hoist a value due to
unaligned/un-dereferencable accesses. However, not only are we doing
sinking rather than hoisting, our concern is that the location
we're loading from may have been modified. Instead forbid sinking
any load across a critical edge.

Reviewers: majnemer

Subscribers: davide, llvm-commits

Differential Revision: https://reviews.llvm.org/D33179

llvm-svn: 305102

as part of a compilation.

This is intended for two purposes:

1) Writing self-contained test cases for modules: we can now write a single
source file test that builds some number of module files on the side and
imports them.

2) Debugging / test case reduction. A single-source testcase is much more
amenable to reduction, compared to a VFS tarball or .pcm files.

llvm-svn: 305101

llvm-svn: 305100

llvm-svn: 305099

Differential Revision: https://reviews.llvm.org/D34046

llvm-svn: 305098

llvm-svn: 305097

It is not needed since we have the disassemble.

llvm-svn: 305096

llvm-svn: 305095

Found by asan.

llvm-svn: 305094

Previously extractors tried to be stateless with any additional
context information needed in order to parse items being passed
in via the extraction method.  This led to quite cumbersome
implementation challenges and awkwardness of use.  This patch
brings back support for stateful extractors, making the
implementation and usage simpler.

llvm-svn: 305093

Summary: Add the WindowsResourceCOFFWriter class for producing the final COFF after all parsing is done.

Reviewers: hiraditya!, zturner, ruiu

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D34020

llvm-svn: 305092

If the inputs won't saturate during packing then we can treat the PACKSS as a truncation shuffle

llvm-svn: 305091

llvm-svn: 305090

This test was silently failing since a long time because it failed to include
stdlib.h (as it's running in a freestanding environment). However, because we
 used just not clang_cc1 instead of the verify mode, this regression was never
 noticed and the test was just always passing.

This adds -ffreestanding to the invocation, so that tmmintrin.h doesn't
indirectly include mm_malloc.h, which in turns includes the unavailable stdlib.h.
We also run now in the -verify mode to prevent that we silently regress again.

I've also updated the test to no longer check the return value of _mm_alignr_epi8
as this is also causing it to fail (and it's not really the job of this test to
test this).


Patch by Raphael Isemann (D34022)

llvm-svn: 305089

Fixes embedded uses of llvm where google testing framework is provided outside.

llvm-svn: 305088

to support operator keywords used in Windows SDK, alter token type when 
seen in system headers

Hello, I submitted D33505 to address this problem, but the 
proposal was rejected as too big a hammer.
This change will allow clang to parse the WindowsSDK header <query.h> 
which uses the operator name "or" as a field name. Treat cpp operator 
keywords as ordinary identifiers inside the Microsoft headers, but 
treat them as usual in the user's program.

Original Submitter: Melanie Blower (mibintc)

Differential Revision: https://reviews.llvm.org/D33782

llvm-svn: 305087

[LazyValueInfo] Don't run the more complex predicate handling code for EQ and NE in getPredicateResult

Summary:
Unless I'm mistaken, the special handling for EQ/NE should cover everything and there is no reason to fallthrough to the more complex code. For that matter I'm not sure there's any reason to special case EQ/NE other than avoiding creating temporary ConstantRanges.

This patch moves the complex code into an else so we only do it when we are handling a predicate other than EQ/NE.

Reviewers: anna, reames, resistor, Farhana

Reviewed By: anna

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D34000

llvm-svn: 305086

- Add some missing patterns.
- Use C4_cmplte in branch patterns.
- Fix signedness of immediate operand in M2_accii.

llvm-svn: 305085

Summary:
During DAG legalization loop in SelectionDAG::Legalize(),
bookkeeping of the SDNodes that were already legalized is implemented
with SmallPtrSet (LegalizedNodes). This kind of set stores only pointers
to objects, not the objects themselves. Unfortunately, if SDNode is
deleted during legalization for some reason, LegalizedNodes set is not
informed about this fact. This wouldn’t be so bad, if SelectionDAG wouldn’t reuse
space deallocated after deletion of unused nodes, for creation of new
ones. Because of this, new nodes, created during legalization often can
have pointers identical to ones that have been previously legalized,
added to the LegalizedNodes set, and deleted afterwards. This in turn
causes, that newly created nodes, sharing the same pointer as deleted
old ones, are present in LegalizedNodes *already at the moment of
creation*, so we never call Legalize on them.
The fix facilitates the fact, that DAG notifies listeners about each
modification. I have registered DAGNodeDeletedListener inside
SelectionDAG::Legalize, with a callback function that removes any
pointer of any deleted SDNode from the LegalizedNodes set. With this
modification, LegalizeNodes set does not contain pointers to nodes that
were deleted, so newly created nodes can always be inserted to it, even
if they share pointers with old deleted nodes.

Patch by pawel.szczerbuk@intel.com

The issue this patch addresses causes failures in an out-of-tree target,
and i was not able to create a reproducer for an in-tree target, hence
there is no test-case.

Reviewers: delena, spatel, RKSimon, hfinkel, davide, qcolombet

Reviewed By: delena

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D33891

llvm-svn: 305084