Commit Graph

10 Commits

Author SHA1 Message Date
Weiming Zhao 1bd40005ba 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
2018-04-11 23:09:20 +00:00
Simon Pilgrim 89d31658e5 Fix 'not all control paths return a value' warning on MSVC builds
llvm-svn: 317790
2017-11-09 14:56:17 +00:00
Sanjoy Das e3992c6328 [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
2017-11-09 06:31:33 +00:00
Chandler Carruth 6bda14b313 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
2017-06-06 11:49:48 +00:00
David Majnemer c700490f48 Use the range variant of remove_if instead of unpacking begin/end
No functionality change is intended.

llvm-svn: 278475
2016-08-12 04:32:37 +00:00
Keno Fischer 875b122dfd [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
2016-01-10 18:17:12 +00:00
Keno Fischer 94f181a45f [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
2015-12-16 11:13:23 +00:00
Keno Fischer 17433bd102 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
2015-10-01 02:45:07 +00:00
Benjamin Kramer efeddcc552 [SectionMemoryManager] Use range-based for loops. No functional change intended.
llvm-svn: 246440
2015-08-31 13:39:14 +00:00
Lang Hames 8a6f35546b [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
2015-02-06 19:36:40 +00:00