[ExecutionEngine] Remove unused includes (NFC) (#116749)

Identified with misc-include-cleaner.

[Kaleidoscope] Fix race condition in order-of-destruction between SectionMemoryManager and its MemoryMapper

SectionMemoryManager's default memory mapper used to be a global static
object. If the Sec

[Kaleidoscope] Fix race condition in order-of-destruction between SectionMemoryManager and its MemoryMapper

SectionMemoryManager's default memory mapper used to be a global static
object. If the SectionMemoryManager itself is a global static
object, it might be destroyed after its memory mapper and thus couldn't
use it from the destructor.

The Kaleidoscope tutorial reproduced this situation with MSVC for a long time.
Since 47f5c54f997a59bb2c65 it's triggered with GCC as well. The solution from
this patch was proposed in the existing review https://reviews.llvm.org/D107087
before, but it didn't move forward.

Reviewed By: nikic

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

show more ...

[llvm] Use = default (NFC)

[llvm] Use nullptr instead of 0 (NFC)

Identified with modernize-use-nullptr.

Revert "[examples] Fix SectionMemoryManager deconstruction error with MSVC."

This reverts commit 63838d88145feaeb839efff8f40ab1e98597e423, which broke tests
on some bots. See e.g. https://lab.llvm.o

Revert "[examples] Fix SectionMemoryManager deconstruction error with MSVC."

This reverts commit 63838d88145feaeb839efff8f40ab1e98597e423, which broke tests
on some bots. See e.g. https://lab.llvm.org/buildbot#builders/109/builds/22561

show more ...

[examples] Fix SectionMemoryManager deconstruction error with MSVC.

This commit fixes an order-of-initialization issue: If the default mmapper
object is destroyed while some global SectionMemoryMana

[examples] Fix SectionMemoryManager deconstruction error with MSVC.

This commit fixes an order-of-initialization issue: If the default mmapper
object is destroyed while some global SectionMemoryManager is still using it
then calls to the mapper from ~SectionMemoryManager will fail. This issue was
causing failures when running the LLVM Kaleidoscope examples on windows.

Switching to a ManagedStatic solves the initialization order issue.

Patch by Justice Adams. Thanks Justice!

Reviewed By: lhames

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

show more ...

[ExecutionEngine, Linker] Use erase_if (NFC)

Do not map read-only data memory sections with EXECUTE flags.

The code in SectionMemoryManager.cpp unnecessarily maps
read-only data sections with the READ+EXECUTE flags. This is
undesirable from a

Do not map read-only data memory sections with EXECUTE flags.

The code in SectionMemoryManager.cpp unnecessarily maps
read-only data sections with the READ+EXECUTE flags. This is
undesirable from a security stand-point.

Moreover, on the Fuchsia platform, which is now very strict
about mapping pages with the EXECUTE permission, this simply
fails, because the section's pages were initially allocated
with only the READ+WRITE flags.

A more detailed description of the issue can be found in this
public SwiftShader bug:

https://issuetracker.google.com/issues/154586551

This patch just restrict the mapping to the READ flag for ROData
sections. Code sections are still mapped with READ+EXECUTE as
expected.

Reviewed By: lhames

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

show more ...

[ExecutionEngine] Initialize near block hint in SectionMemoryManager.

When allocating a new memory block in SectionMemoryManager, initialize
the Near hint for the other memory groups if they have no

[ExecutionEngine] Initialize near block hint in SectionMemoryManager.

When allocating a new memory block in SectionMemoryManager, initialize
the Near hint for the other memory groups if they have not been set
already.

Patch by Dana Koch. Thanks Dana!

show more ...

[Support] Renamed member 'Size' to 'AllocatedSize' in MemoryBlock and OwningMemoryBlock.

Rename member 'Size' to 'AllocatedSize' in order to provide a hint that the
allocated size may be different t

[Support] Renamed member 'Size' to 'AllocatedSize' in MemoryBlock and OwningMemoryBlock.

Rename member 'Size' to 'AllocatedSize' in order to provide a hint that the
allocated size may be different than the requested size. Comments are added to
clarify this point. Updated the InMemoryBuffer in FileOutputBuffer.cpp to track
the requested buffer size.

Patch by Machiel van Hooren. Thanks Machiel!

https://reviews.llvm.org/D61599

llvm-svn: 361195

show more ...

[Support] Add error handling to sys::Process::getPageSize().

This patch changes the return type of sys::Process::getPageSize to
Expected<unsigned> to account for the fact that the underlying syscall

[Support] Add error handling to sys::Process::getPageSize().

This patch changes the return type of sys::Process::getPageSize to
Expected<unsigned> to account for the fact that the underlying syscalls used to
obtain the page size may fail (see below).

For clients who use the page size as an optimization only this patch adds a new
method, getPageSizeEstimate, which calls through to getPageSize but discards
any error returned and substitues a "reasonable" page size estimate estimate
instead. All existing LLVM clients are updated to call getPageSizeEstimate
rather than getPageSize.

On Unix, sys::Process::getPageSize is implemented in terms of getpagesize or
sysconf, depending on which macros are set. The sysconf call is documented to
return -1 on failure. On Darwin getpagesize is implemented in terms of sysconf
and may also fail (though the manpage documentation does not mention this).
These failures have been observed in practice when highly restrictive sandbox
permissions have been applied. Without this patch, the result is that
getPageSize returns -1, which wreaks havoc on any subsequent code that was
assuming a sane page size value.

<rdar://problem/41654857>

Reviewers: dblaikie, echristo

Subscribers: kristina, llvm-commits

Tags: #llvm

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

llvm-svn: 360221

show more ...

MemoryBlock: Do not automatically extend a given size to a multiple of page size.

Previously, MemoryBlock automatically extends a requested buffer size to a
multiple of page size because (I believe)

MemoryBlock: Do not automatically extend a given size to a multiple of page size.

Previously, MemoryBlock automatically extends a requested buffer size to a
multiple of page size because (I believe) doing it was thought to be harmless
and with that you could get more memory (on average 2KiB on 4KiB-page systems)
"for free".

That programming interface turned out to be error-prone. If you request N
bytes, you usually expect that a resulting object returns N for `size()`.
That's not the case for MemoryBlock.

Looks like there is only one place where we take the advantage of
allocating more memory than the requested size. So, with this patch, I
simply removed the automatic size expansion feature from MemoryBlock
and do it on the caller side when needed. MemoryBlock now always
returns a buffer whose size is equal to the requested size.

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

llvm-svn: 351916

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 ...

Add missing vtable anchors

Summary: This patch adds anchor() for MemoryBuffer, raw_fd_ostream, RTDyldMemoryManager, SectionMemoryManager, etc.

Reviewers: jlebar, eli.friedman, dblaikie

Reviewed By

Add missing vtable anchors

Summary: This patch adds anchor() for MemoryBuffer, raw_fd_ostream, RTDyldMemoryManager, SectionMemoryManager, etc.

Reviewers: jlebar, eli.friedman, dblaikie

Reviewed By: dblaikie

Subscribers: mehdi_amini, mgorny, dblaikie, weimingz, llvm-commits

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

llvm-svn: 329861

show more ...

Fix 'not all control paths return a value' warning on MSVC builds

llvm-svn: 317790

[SectionMemoryManager] Abstract out mmap, munmap, mprotect even more ; NFC

Summary:
This will let ORC JIT clients plug in custom logic for the mmap, munmap and
mprotect paths.

Reviewers: loladiro,

[SectionMemoryManager] Abstract out mmap, munmap, mprotect even more ; NFC

Summary:
This will let ORC JIT clients plug in custom logic for the mmap, munmap and
mprotect paths.

Reviewers: loladiro, dblaikie

Subscribers: mcrosier, llvm-commits

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

llvm-svn: 317770

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 ...

Use the range variant of remove_if instead of unpacking begin/end

No functionality change is intended.

llvm-svn: 278475

[SectionMemoryManager] Don't just drop the RO free list

In r255760, I optimized the SectionMemoryManager to make better use
of virtual memory on platforms where the allocation granularity was
bigger

[SectionMemoryManager] Don't just drop the RO free list

In r255760, I optimized the SectionMemoryManager to make better use
of virtual memory on platforms where the allocation granularity was
bigger than the protection granularity. As part of this, fixing up
the free list became more complicated and was moved into
`applyMemoryGroupPermissions`. Unfortunately, I forgot to actually
remove the call that drops the free list for RO memory (I did
remove the corresponding one for RX memory), defeating the whole
optimization.

llvm-svn: 257293

show more ...

[SectionMemoryManager] Make better use of virtual memory

Summary: On Windows, the allocation granularity can be significantly
larger than a page (64K), so with many small objects, just clearing
the

[SectionMemoryManager] Make better use of virtual memory

Summary: On Windows, the allocation granularity can be significantly
larger than a page (64K), so with many small objects, just clearing
the FreeMem list rapidly leaks quite a bit of virtual memory space
(if not rss). Fix that by only removing those parts of the FreeMem
blocks that overlap pages for which we are applying memory permissions,
rather than dropping the FreeMem blocks entirely.

Reviewers: lhames

Subscribers: llvm-commits

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

llvm-svn: 255760

show more ...

Fix performance problem in long-running SectionMemoryManagers

Summary:
Without this patch, the memory manager would call `mprotect` on every memory
region it ever allocated whenever it wanted to fin

Fix performance problem in long-running SectionMemoryManagers

Summary:
Without this patch, the memory manager would call `mprotect` on every memory
region it ever allocated whenever it wanted to finalize memory (i.e. not just
the ones it just allocated). This caused terrible performance problems for
long running memory managers. In one particular compile heavy julia benchmark,
we were spending 50% of time in `mprotect` if running under MCJIT.

Fix this by splitting allocated memory blocks into those on which memory
permissions have been set and those on which they haven't and only running
`mprotect` on the latter.

Reviewers: lhames

Subscribers: reames, llvm-commits

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

llvm-svn: 248981

show more ...

[SectionMemoryManager] Use range-based for loops. No functional change intended.

llvm-svn: 246440

[Orc] Move SectionMemoryManager's implementation from MCJIT to ExecutionEngine.

This is a more sensible home for SectionMemoryManager, and allows the implementation
to be shared between Orc and MCJI

[Orc] Move SectionMemoryManager's implementation from MCJIT to ExecutionEngine.

This is a more sensible home for SectionMemoryManager, and allows the implementation
to be shared between Orc and MCJIT.

llvm-svn: 228427

show more ...