Use llvm_unreachable for unsupported integer types.

As suggested on rG937c4cffd024, use llvm_unreachable for unhandled integer types (which shouldn't be possible) instead of breaking and dropping do

Use llvm_unreachable for unsupported integer types.

As suggested on rG937c4cffd024, use llvm_unreachable for unhandled integer types (which shouldn't be possible) instead of breaking and dropping down to the existing fatal error handler.

Helps silence static analyzer warnings.

show more ...

Fix implicit fall through compiler warning. NFCI.

[llvm] Use llvm::append_range (NFC)

Make StringRef's std::string conversion operator explicit
The build is currenly broken when perf or ffi are enabled for llvm

Just like in https://reviews.llvm.org/rG777180a32b61070a10dd330b4f038bf24

Make StringRef's std::string conversion operator explicit
The build is currenly broken when perf or ffi are enabled for llvm

Just like in https://reviews.llvm.org/rG777180a32b61070a10dd330b4f038bf24e916af1

show more ...

Replace llvm::MutexGuard/UniqueLock with their standard equivalents

All supported platforms have <mutex> now, so we don't need our own
copies any longer. No functionality change intended.

llvm-svn:

Replace llvm::MutexGuard/UniqueLock with their standard equivalents

All supported platforms have <mutex> now, so we don't need our own
copies any longer. No functionality change intended.

llvm-svn: 368149

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

[opaque pointer types] Remove some calls to generic Type subtype accessors.

That is, remove many of the calls to Type::getNumContainedTypes(),
Type::subtypes(), and Type::getContainedType(N).

I'm n

[opaque pointer types] Remove some calls to generic Type subtype accessors.

That is, remove many of the calls to Type::getNumContainedTypes(),
Type::subtypes(), and Type::getContainedType(N).

I'm not intending to remove these accessors -- they are
useful/necessary in some cases. However, removing the pointee type
from pointers would potentially break some uses, and reducing the
number of calls makes it easier to audit.

llvm-svn: 350835

show more ...

[ExecutionEngine][Interpreter] Fix out-of-bounds array access.

If args is empty then accesing element 0 is illegal.

https://reviews.llvm.org/D53556

Patch by Eugene Sharygin. Thanks Eugene!

llvm-s

[ExecutionEngine][Interpreter] Fix out-of-bounds array access.

If args is empty then accesing element 0 is illegal.

https://reviews.llvm.org/D53556

Patch by Eugene Sharygin. Thanks Eugene!

llvm-svn: 347281

show more ...

Sort the remaining #include lines in include/... and lib/....

I did this a long time ago with a janky python script, but now
clang-format has built-in support for this. I fed clang-format every
line

Sort the remaining #include lines in include/... and lib/....

I did this a long time ago with a janky python script, but now
clang-format has built-in support for this. I fed clang-format every
line with a #include and let it re-sort things according to the precise
LLVM rules for include ordering baked into clang-format these days.

I've reverted a number of files where the results of sorting includes
isn't healthy. Either places where we have legacy code relying on
particular include ordering (where possible, I'll fix these separately)
or where we have particular formatting around #include lines that
I didn't want to disturb in this patch.

This patch is *entirely* mechanical. If you get merge conflicts or
anything, just ignore the changes in this patch and run clang-format
over your #include lines in the files.

Sorry for any noise here, but it is important to keep these things
stable. I was seeing an increasing number of patches with irrelevant
re-ordering of #include lines because clang-format was used. This patch
at least isolates that churn, makes it easy to skip when resolving
conflicts, and gets us to a clean baseline (again).

llvm-svn: 304787

show more ...

Fix some Clang-tidy modernize-use-using and Include What You Use warnings; other minor fixes.

Differential revision: https://reviews.llvm.org/D23789

llvm-svn: 279535

Fix ffiInvoke() use of DataLayout, broken in 242414

From: Mehdi Amini <[email protected]>
llvm-svn: 242456

Make ExecutionEngine owning a DataLayout

Summary:
This change is part of a series of commits dedicated to have a single
DataLayout during compilation by using always the one owned by the
module.

Th

Make ExecutionEngine owning a DataLayout

Summary:
This change is part of a series of commits dedicated to have a single
DataLayout during compilation by using always the one owned by the
module.

The ExecutionEngine will act as an exception and will be unsafe to
be reused across context. We don't enforce this rule but undefined
behavior can occurs if the user tries to do it.

Reviewers: lhames

Subscribers: echristo, llvm-commits, rafael, yaron.keren

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

From: Mehdi Amini <[email protected]>
llvm-svn: 242414

show more ...

Revert "Make ExecutionEngine owning a DataLayout"

Reverting to fix buildbot breakage.

This reverts commit r242387.

llvm-svn: 242394

Make ExecutionEngine owning a DataLayout

Summary:
This change is part of a series of commits dedicated to have a single
DataLayout during compilation by using always the one owned by the
module.

Th

Make ExecutionEngine owning a DataLayout

Summary:
This change is part of a series of commits dedicated to have a single
DataLayout during compilation by using always the one owned by the
module.

The ExecutionEngine will act as an exception and will be unsafe to
be reused across context. We don't enforce this rule but undefined
behavior can occurs if the user tries to do it.

Reviewers: lhames

Subscribers: echristo, llvm-commits, rafael, yaron.keren

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

From: Mehdi Amini <[email protected]>
llvm-svn: 242387

show more ...

[ExecutionEngine] ArrayRefize argument passing.

No functionality change intended.

llvm-svn: 239687

Remove more superfluous .str() and replace std::string concatenation with Twine.

Following r233392, http://llvm.org/viewvc/llvm-project?rev=233392&view=rev.

llvm-svn: 233555

Converting FuncNames to a ManagedStatic to avoid static constructors and destructors.

llvm-svn: 218151

Support: add llvm::unique_lock

Based on the STL class of the same name, it guards a mutex
while also allowing it to be unlocked conditionally before
destruction.

This eliminates the last naked usag

Support: add llvm::unique_lock

Based on the STL class of the same name, it guards a mutex
while also allowing it to be unlocked conditionally before
destruction.

This eliminates the last naked usages of mutexes in LLVM and
clang.

It also uncovered and fixed a bug in callExternalFunction()
when compiled without USE_LIBFFI, where the mutex would never
be unlocked if the end of the function was reached.

llvm-svn: 216338

show more ...

Support: make LLVM Mutexes STL-compatible

Use lock/unlock() convention instead of acquire/release().

llvm-svn: 216336

[C++] Use 'nullptr'.

llvm-svn: 207083

Don't expose symbols of lle_ functions.

+ formatting fixes.

llvm-svn: 190523

llvm interpreter: select, shuffle and insertelement instructions.
This patch implements vector support for select instruction and adds specific vector instructions : shuffle and insertelement. (test

llvm interpreter: select, shuffle and insertelement instructions.
This patch implements vector support for select instruction and adds specific vector instructions : shuffle and insertelement. (tests are also included)
and functions lle_X_memset, lle_X_memcpy added.

Done by Veselov, Yuri (mailto:[email protected])

llvm-svn: 189735

show more ...

Move all of the header files which are involved in modelling the LLVM IR
into their new header subdirectory: include/llvm/IR. This matches the
directory structure of lib, and begins to correct a long

Move all of the header files which are involved in modelling the LLVM IR
into their new header subdirectory: include/llvm/IR. This matches the
directory structure of lib, and begins to correct a long standing point
of file layout clutter in LLVM.

There are still more header files to move here, but I wanted to handle
them in separate commits to make tracking what files make sense at each
layer easier.

The only really questionable files here are the target intrinsic
tablegen files. But that's a battle I'd rather not fight today.

I've updated both CMake and Makefile build systems (I think, and my
tests think, but I may have missed something).

I've also re-sorted the includes throughout the project. I'll be
committing updates to Clang, DragonEgg, and Polly momentarily.

llvm-svn: 171366

show more ...

Use the new script to sort the includes of every file under lib.

Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module

Use the new script to sort the includes of every file under lib.

Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.

Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]

llvm-svn: 169131

show more ...

Revert the majority of the next patch in the address space series:

r165941: Resubmit the changes to llvm core to update the functions to
support different pointer sizes on a per address spa

Revert the majority of the next patch in the address space series:

r165941: Resubmit the changes to llvm core to update the functions to
support different pointer sizes on a per address space basis.

Despite this commit log, this change primarily changed stuff outside of
VMCore, and those changes do not carry any tests for correctness (or
even plausibility), and we have consistently found questionable or flat
out incorrect cases in these changes. Most of them are probably correct,
but we need to devise a system that makes it more clear when we have
handled the address space concerns correctly, and ideally each pass that
gets updated would receive an accompanying test case that exercises that
pass specificaly w.r.t. alternate address spaces.

However, from this commit, I have retained the new C API entry points.
Those were an orthogonal change that probably should have been split
apart, but they seem entirely good.

In several places the changes were very obvious cleanups with no actual
multiple address space code added; these I have not reverted when
I spotted them.

In a few other places there were merge conflicts due to a cleaner
solution being implemented later, often not using address spaces at all.
In those cases, I've preserved the new code which isn't address space
dependent.

This is part of my ongoing effort to clean out the partial address space
code which carries high risk and low test coverage, and not likely to be
finished before the 3.2 release looms closer. Duncan and I would both
like to see the above issues addressed before we return to these
changes.

llvm-svn: 167222

show more ...