This change fixes a bug in which the Mips LA25 Thunks are always assigned
to the same Output section as the caller and not the callee as expected.

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

llvm-svn: 297135

Summary: Previously, it had always been materialized as a push/pop sequence.

Reviewers: labrinea, jroelofs

Reviewed By: jroelofs

Subscribers: llvm-commits, rengolin

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

llvm-svn: 297134

llvm-svn: 297133

Propagate debug info through the newly inserted PHI nodes.

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

llvm-svn: 297132

[AST/ObjC] Make ObjCCategoryImplDecl consistent with ObjCCategoryDecl and use the category name as its DeclName

This also addresses the badness in ObjCCategoryImplDecl's API, which was hiding NamedDecl's APIs with different meaning.

llvm-svn: 297131

llvm-svn: 297130

Summary:
I've included a unit test with a function template containing a variable
of incomplete type. Clang compiles this without errors (the standard
does not require a diagnostic in this case). Without the fix, this case
triggers the crash.

Reviewers: klimek

Reviewed By: klimek

Subscribers: cfe-commits

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

llvm-svn: 297129

llvm-svn: 297128

X86EvexToVex machine instruction pass compresses EVEX encoded instructions by replacing them with their identical VEX encoded instructions when possible.
It uses manually supported 2 large tables that map the EVEX instructions to their VEX ideticals.
This TableGen backend replaces the tables by automatically generating them.

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

llvm-svn: 297127

evex2vex pass defines 2 tables which maps EVEX instructions to their VEX identical when possible. Adding all missing entries.

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

llvm-svn: 297126

This reverts commit r296771.

We found some wide spread test failures internally. I'm working on a
testcase. Politely revert the patch in the mean time. :)

llvm-svn: 297124

Summary:
We should check if loop size allows us to peel at least one iteration
before we do so.

Patch by Max Kazantsev!

Reviewers: sanjoy, mkuper, efriedma

Reviewed By: mkuper

Subscribers: llvm-commits

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

llvm-svn: 297122

[APInt] Add rvalue reference support to and, or, xor operations to allow their memory allocation to be reused when possible

This extends an earlier change that did similar for add and sub operations.

With this first patch we lose the fastpath for the single word case as operator&= and friends don't support it. This can be added there if we think that's important.

I had to change some functions in the APInt class since the operator overloads were moved out of the class and can't be used inside the class now. The getBitsSet change collides with another outstanding patch to implement it with setBits. But I didn't want to make this patch dependent on that series.

I've also removed the Or, And, Xor functions which were rarely or never used. I already commited two changes to remove the only uses of Or that existed.

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

llvm-svn: 297121

llvm-svn: 297120

llvm-svn: 297119

It breaks line tables because the patch is not complete, working on a complete one at the moment

This reverts commit r294031.

llvm-svn: 297118

llvm-svn: 297117

This deletes LLDB's FileType enumeration and replaces all
users, and all calls to functions that check whether a file
exists etc with corresponding calls to LLVM.

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

llvm-svn: 297116

llvm-svn: 297115

We currently have methods to set a specified number of low bits, a specified number of high bits, or a range of bits. But looking at some existing code it seems sometimes we want to set the high bits starting from a certain bit. Currently we do this with something like getHighBits(BitWidth, BitWidth - StartBit). Or once we start switching to setHighBits, setHighBits(BitWidth - StartBit) or setHighBits(getBitWidth() - StartBit).

Particularly for the latter case it would be better to have a convenience method like setBitsFrom(StartBit) so we don't need to mention the bit width that's already known to the APInt object.

I considered just making setBits have a default value of UINT_MAX for the hiBit argument and we would internally MIN it with the bit width. So if it wasn't specified it would be treated as bit width. This would require removing the assertion we currently have on the value of hiBit and may not be as readable.

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

llvm-svn: 297114

Check that missing debug locations on inlinable calls are a
recoverable error.

llvm-svn: 297113

This patch implements getLowBitsSet/getHighBitsSet/getBitsSet in terms of the new setLowBits/setHighBits/setBits methods by making an all 0s APInt and then calling the appropriate set method.

This also adds support to setBits to allow loBits/hiBits to be in the other order to match with getBitsSet behavior.

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

llvm-svn: 297112

Summary:
There are quite a few places in the code base that do something like the following to set the high or low bits in an APInt.

KnownZero |= APInt::getHighBitsSet(BitWidth, BitWidth - 1);

For BitWidths larger than 64 this creates a short lived APInt with malloced storage. I think it might even call malloc twice. Its better to just provide methods that can set the necessary bits without the temporary APInt.

I'll update usages that benefit in a separate patch.

Reviewers: majnemer, MatzeB, davide, RKSimon, hans

Reviewed By: hans

Subscribers: llvm-commits

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

llvm-svn: 297111

llvm-svn: 297110

This is a follow-up to my change in r295090, which added support for
disabling these checks selectively based on setting the preprocessor
macro without relying on the Cmake setting. Swift has moved over to use
that approach, so we can clean up here and remove the Cmake setting.

https://reviews.llvm.org/D30578

llvm-svn: 297109

llvm-svn: 297108

llvm-svn: 297107

llvm-svn: 297106

llvm-svn: 297105

llvm-svn: 297104

Details and reproducer are on the email thread for r296863.

llvm-svn: 297103

llvm-svn: 297102

llvm-svn: 297101

A bit more painful than G_INSERT because it was more widely used, but this
should simplify the handling of extract operations in most locations.

llvm-svn: 297100

llvm-svn: 297099

llvm-svn: 297098

All it really needs is the llvm::Triple, so make FileSpec take
the Triple directly instead of the ArchSpec.

llvm-svn: 297096

This functionality is subsumed by DataBufferLLVM, which is
also more efficient since it will try to mmap.  However, we
don't yet support mmaping writable private sections, and in
some cases we were using ReadFileContents and then modifying
the buffer.  To address that I've added a flag to the
DataBufferLLVM methods that allow you to map privately, which
disables the mmaping path entirely.  Eventually we should teach
DataBufferLLVM to use mmap with writable private, but that is
orthogonal to this effort.

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

llvm-svn: 297095

Summary:
After https://reviews.llvm.org/rL296904 xargs shouldn't be necesssary.

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

llvm-svn: 297094

Summary:
The changes contained in this patch are:

1. Defines a new AST node `CoawaitDependentExpr` for representing co_await expressions while the promise type is still dependent.
2. Correctly detect and transform the 'co_await' operand to  `p.await_transform(<expr>)`  when possible.
3. Change the initial/final suspend points to build during the initial parse, so they have the correct operator co_await lookup results.
4.  Fix transformation of the CoroutineBodyStmt so that it doesn't re-build the final/initial suspends.


@rsmith: This change is a little big, but it's not trivial for me to split it up. Please let me know if you would prefer this submitted as multiple patches.



Reviewers: rsmith, GorNishanov

Reviewed By: rsmith

Subscribers: ABataev, rsmith, mehdi_amini, cfe-commits

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

llvm-svn: 297093