An error that is pretty easy to make is to use the lazy bitcode reader
and then do something like

if (V.use_empty())

The problem is that uses in unmaterialized functions are not accounted
for.

This patch adds asserts that all uses are known.

llvm-svn: 256105

The test will mainly be useful to check that the .s file assembles and relocates properly because vtables reference functions in their data section.

llvm-svn: 256102

llvm-svn: 256101

llvm-svn: 256100

llvm-svn: 256099

SDIV and UDIV had special handling, but this is the same handling
that min/max need.

llvm-svn: 256098

llvm-svn: 256097

llvm-svn: 256096

Make personality functions, prefix data, and prologue data hungoff
operands of Function.

This is based on the email thread "[RFC] Clean up the way we store
optional Function data" on llvm-dev.

Thanks to sanjoyd, majnemer, rnk, loladiro, and dexonsmith for feedback!

Includes a fix to scrub value subclass data in dropAllReferences. Does not
use binary literals.

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

llvm-svn: 256095

This reverts commit r256093.

This broke lld-x86_64-win7 because of -Werror,-Wc++1y-extensions.

llvm-svn: 256094

Make personality functions, prefix data, and prologue data hungoff
operands of Function.

This is based on the email thread "[RFC] Clean up the way we store
optional Function data" on llvm-dev.

Thanks to sanjoyd, majnemer, rnk, loladiro, and dexonsmith for feedback!

Includes a fix to scrub value subclass data in dropAllReferences.

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

llvm-svn: 256093

Creator and lookup interfaces are added to this symtab class.
The new interfaces will be used by InstrProf Readers and writer.

A unit test is also added for the new APIs.

llvm-svn: 256092

This reverts commit r256090.

This broke llvm-clang-lld-x86_64-debian-fast.

llvm-svn: 256091

Make personality functions, prefix data, and prologue data hungoff
operands of Function.

This is based on the email thread "[RFC] Clean up the way we store
optional Function data" on llvm-dev.

Thanks to sanjoyd, majnemer, rnk, loladiro, and dexonsmith for feedback!

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

llvm-svn: 256090

Follow-up to r256056.

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

llvm-svn: 256086

llvm-svn: 256085

llc_dwarf adds an mtriple, which forces this to use COFF, causing
the test to fail. Hopefully using regular llc without the triple
will work fine everywhere

llvm-svn: 256084

Summary:
The analysis of shader inputs was completely wrong.  We were passing the
wrong index to AttributeSet::hasAttribute() and the logic for which
inputs where in SGPRs was wrong too.

Reviewers: arsenm

Subscribers: arsenm, llvm-commits

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

llvm-svn: 256082

llvm-svn: 256081

As shown by the included test case, it's reasonable to end up with constant references during base pointer calculation.  The code actually handled this case just fine, we only had the assert to help isolate problems under the belief that constant references shouldn't be present in IR generated by managed frontends. This turned out to be wrong on two fronts: 1) Manual Jacobs is working on a language with constant references, and b) we found a case where the optimizer does create them in practice.

llvm-svn: 256079

Summary:
First up is instcombine, where in the dbg.declare -> dbg.value conversion,
the llvm.dbg.value needs to be called on the actual loaded value, rather
than the address (since the whole point of this transformation is to be
able to get rid of the alloca). Further, now that that's cleaned up, we
can remove a hack in the backend, that would add an implicit OP_deref if
the argument to dbg.value was an alloca. This stems from before the
existence of DIExpression and is no longer necessary since the deref can
be expressed explicitly.

Now, in order to make sure that the tests pass with this change, we need to
correct the printing of DEBUG_VALUE comments to take into account the
expression, which wasn't taken into account before.

Unfortunately, for both these changes, there were a number of incorrect
test cases (mostly the wrong number of DW_OP_derefs, but also a couple
where the test itself was broken more badly). aprantl and I have gone
through and adjusted these test case in order to make them pass with
these fixes and in some cases to make sure they're actually testing
what they are meant to test.

Reviewers: aprantl

Subscribers: dsanders

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

llvm-svn: 256077

noduplicate prevents unrolling of small loops that happen to have
barriers in them. If a loop has a barrier in it, it is OK to duplicate
it for the unroll.

llvm-svn: 256075

This was using an anyext when promoting the type
when zext/sext is required.

llvm-svn: 256074

Reviewers: arsenm, tstellarAMD

Subscribers: arsenm, llvm-commits

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

llvm-svn: 256073

Summary:
When copying aggregate registers within the same register class, there may
be an overlap between source and destination that forces us to do the copy
backwards.

Do the simplest possible thing that guarantees the correct order of moves
when there are overlaps, and does whatever when there is no overlap. (The
last part forces some trivial adjustments to test cases.)

Together with r255906, this fixes a VM fault in Unreal Elemental Demo.

While at it, change the generation of kill and def flags to something that
looks more reasonable. This method is used very late during compilation, so
it probably doesn't matter in practice, and to be honest, I don't know if
this change is actually correct because the semantics in connection with
aggregate registers vs. sub-registers are not clear to me.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93264

Reviewers: arsenm, tstellarAMD

Subscribers: arsenm, llvm-commits

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

llvm-svn: 256072

llvm-svn: 256071

I don't have any way to test MSVC compilation, but maybe this will fix
the error:

llvm/Support/TrailingObjects.h(286) : error C3210: 'TrailingObjectsBase' : access declaration can only be applied to a base class member
llvm/Support/TrailingObjects.h(337) : see reference to class template instantiation 'llvm::TrailingObjects<BaseTy,TrailingTys...>' being compiled
llvm/Support/TrailingObjects.h(286) : error C2602: 'llvm::trailing_objects_internal::TrailingObjectsBase::OverloadToken' is not a member of a base class of 'llvm::TrailingObjects<BaseTy,TrailingTys...>'
llvm/Support/TrailingObjects.h(91) : see declaration of 'llvm::trailing_objects_internal::TrailingObjectsBase::OverloadToken'

llvm-svn: 256068

This deprecates:
* LLVMParseBitcode
* LLVMParseBitcodeInContext
* LLVMGetBitcodeModuleInContext
* LLVMGetBitcodeModule

They are replaced with the functions with a 2 suffix which do not record
a diagnostic.

llvm-svn: 256065

llvm-svn: 256058

Remove all checks that required main thread to run faster than tasks in
ThreadPool, and yields which are now unnecessary. This should fix some
bot failures.

llvm-svn: 256056

 - Automatic alignment of the base type for the alignment requirements
   of the trailing types.

 - Support for an arbitrary numbers of trailing types, instead of only
   1 or 2, by using a variadic template implementation.

Upcoming commits to clang will take advantage of both of these features.

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

llvm-svn: 256054

llvm-svn: 256052

llvm-svn: 256050

llvm-svn: 256048

llvm-svn: 256047

This code changes the way Symbolize handles parsed binaries: now
parsed OwningBinary<Binary> is not broken into (binary, memory buffer)
pair, and is just stored as-is in a cache. ObjectFile components
of Mach-O universal binaries are also stored explicitly in a
separate cache.

Additionally, this change:
* simplifies the code that parses/caches binaries: it's now done
  in a single place, not three different functions.
* makes flush() method behave as expected, and actually clear
  the cached parsed binaries and objects.
* fixes a dangling pointer issue described in
  http://reviews.llvm.org/D15638

llvm-svn: 256041

llvm-svn: 256040

Use getEdgeProbability() instead of getEdgeWeight() in BFI and remove getEdgeWeight() interfaces from MBPI.

This patch removes all getEdgeWeight() interfaces from CodeGen directory. As
getEdgeProbability() is a little more expensive than getEdgeWeight(), I will
compose a patch soon in which BPI only stores probabilities instead of edge
weights so that getEdgeProbability() will have O(1) time.


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

llvm-svn: 256039

Fixes PR25864

llvm-svn: 256036