Cleanup include: TableGen

This also includes a few cleanup from Support.

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.l

Cleanup include: TableGen

This also includes a few cleanup from Support.

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D121331

show more ...

[Support][mips] Remove unnecessary includes from Memory.inc

The mips-specific includes have been unnecessary ever since the
__clear_cache() builtin replaced cacheflush().

Differential Revision: htt

[Support][mips] Remove unnecessary includes from Memory.inc

The mips-specific includes have been unnecessary ever since the
__clear_cache() builtin replaced cacheflush().

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

show more ...

Fix header includes after 0697bcb66f1d82f2fd447e9d13b74d141c3ce085

[Support][NFC] Make some helper functions "static" in Memory.inc

[Alignment][NFC] Move and type functions from MathExtras to Alignment

Summary:
This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pi

[Alignment][NFC] Move and type functions from MathExtras to Alignment

Summary:
This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
See this patch for the introduction of the type: https://reviews.llvm.org/D64790

Reviewers: courbet

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 374773

show more ...

[PowerPC] Set PROT_READ flag for MF_EXEC to prevent segfaults on PPC machines

The big endian PPC buildbots are all failing now due to calls to cache
invalidation in unit tests on data that has only

[PowerPC] Set PROT_READ flag for MF_EXEC to prevent segfaults on PPC machines

The big endian PPC buildbots are all failing now due to calls to cache
invalidation in unit tests on data that has only the PROT_EXEC flag set.
This has been an issue all along on FreeBSD but it can affect Linux machines
depending on configuration.

This patch mitigates the issue the same way it is mitigated on FreeBSD.

Since this is needed to bring the buildbots back to green, I plan to commit this
and allow for post-commit review, but I thought I would also post it here for
ease of access/readability.

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

llvm-svn: 362412

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

Fixes for builds that require strict X/Open and POSIX compatiblity

Summary:
- Use alternative to MAP_ANONYMOUS for allocating mapped memory if it isn't available
- Use strtok_r instead of strsep as

Fixes for builds that require strict X/Open and POSIX compatiblity

Summary:
- Use alternative to MAP_ANONYMOUS for allocating mapped memory if it isn't available
- Use strtok_r instead of strsep as part of getting program path
- Don't try to find the width of a terminal using "struct winsize" and TIOCGWINSZ on POSIX builds. These aren't defined under POSIX (even though some platforms make them available when they shouldn't), so just check if we are doing a X/Open or POSIX compliant build first.

Author: daltenty

Reviewers: hubert.reinterpretcast, xingxue, andusy

Reviewed By: hubert.reinterpretcast

Subscribers: MaskRay, jsji, hiraditya, kristina, llvm-commits

Tags: #llvm

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

llvm-svn: 360898

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

[Support] Don't check MAP_ANONYMOUS, just use MAP_ANON

Though being marked "deprecated" by the Linux man-pages project
(MAP_ANON is a synonym of MAP_ANONYMOUS), it is the mostly widely
available mac

[Support] Don't check MAP_ANONYMOUS, just use MAP_ANON

Though being marked "deprecated" by the Linux man-pages project
(MAP_ANON is a synonym of MAP_ANONYMOUS), it is the mostly widely
available macro - many systems that don't provide MAP_ANONYMOUS have
MAP_ANON. MAP_ANON is also used here and there in compiler-rt.

llvm-svn: 359758

show more ...

Fix non-Windows platforms build break introduced by r355065. Fixes:

In file included from /home/buildbots/ppc64le-lld-multistage-test/ppc64le-lld-multistage-test/llvm/lib/Support/Memory.cpp:14:
/hom

Fix non-Windows platforms build break introduced by r355065. Fixes:

In file included from /home/buildbots/ppc64le-lld-multistage-test/ppc64le-lld-multistage-test/llvm/lib/Support/Memory.cpp:14:
/home/buildbots/ppc64le-lld-multistage-test/ppc64le-lld-multistage-test/llvm/include/llvm/Support/Memory.h:38:14: error: private field 'Flags' is not used [-Werror,-Wunused-private-field]
unsigned Flags = 0;
^
1 error generated.

llvm-svn: 355066

show more ...

[Memory] Add basic support for large/huge memory pages

This patch introduces Memory::MF_HUGE_HINT which indicates that allocateMappedMemory() shall return a pointer to a large memory page.
However t

[Memory] Add basic support for large/huge memory pages

This patch introduces Memory::MF_HUGE_HINT which indicates that allocateMappedMemory() shall return a pointer to a large memory page.
However the flag is a hint because we're not guaranteed in any way that we will get back a large memory page. There are several restrictions:

- Large/huge memory pages aren't enabled by default on modern OSes (Windows 10 and Linux at least), and should be manually enabled/reserved.
- Once enabled, it should be kept in mind that large pages are physical only, they can't be swapped.
- Memory fragmentation can affect the availability of large pages, especially after running the OS for a long time and/or running along many other applications.

Memory::allocateMappedMemory() will fallback to 4KB pages if it can't allocate 2MB large pages (if Memory::MF_HUGE_HINT is provided)

Currently, Memory::MF_HUGE_HINT only works on Windows. The hint will be ignored on Linux, 4KB pages will always be returned.

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

llvm-svn: 355065

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

[Support] Use zx_cache_flush on Fuchsia to flush instruction cache

Fuchsia doesn't use __clear_cache, instead it provide zx_cache_flush
system call. Use it to flush instruction cache.

Differential

[Support] Use zx_cache_flush on Fuchsia to flush instruction cache

Fuchsia doesn't use __clear_cache, instead it provide zx_cache_flush
system call. Use it to flush instruction cache.

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

llvm-svn: 334068

show more ...

IWYU for llvm-config.h in llvm, additions.

See r331124 for how I made a list of files missing the include.
I then ran this Python script:

for f in open('filelist.txt'):
f = f.strip()

IWYU for llvm-config.h in llvm, additions.

See r331124 for how I made a list of files missing the include.
I then ran this Python script:

for f in open('filelist.txt'):
f = f.strip()
fl = open(f).readlines()

found = False
for i in xrange(len(fl)):
p = '#include "llvm/'
if not fl[i].startswith(p):
continue
if fl[i][len(p):] > 'Config':
fl.insert(i, '#include "llvm/Config/llvm-config.h"\n')
found = True
break
if not found:
print 'not found', f
else:
open(f, 'w').write(''.join(fl))

and then looked through everything with `svn diff | diffstat -l | xargs -n 1000 gvim -p`
and tried to fix include ordering and whatnot.

No intended behavior change.

llvm-svn: 331184

show more ...

[ARM][AArch64] Workaround ARM/AArch64 peculiarity in clearing icache.

Certain ARM implementations treat icache clear instruction as a memory read,
and CPU segfaults on trying to clear cache on !PROT

[ARM][AArch64] Workaround ARM/AArch64 peculiarity in clearing icache.

Certain ARM implementations treat icache clear instruction as a memory read,
and CPU segfaults on trying to clear cache on !PROT_READ page.
We workaround this in Memory::protectMappedMemory by adding
PROT_READ to affected pages, clearing the cache, and then setting
desired protection.

This fixes "AllocationTests/MappedMemoryTest.***/3" unit-tests on
affected hardware.

Reviewers: psmith, zatrazz, kristof.beyls, lhames

Reviewed By: lhames

Subscribers: llvm-commits, krytarowski, peter.smith, jgreenhalgh, aemerson,
rengolin

Patch by maxim-kuvrykov!

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

llvm-svn: 319166

show more ...

[Support] Support NetBSD PaX MPROTECT in sys::Memory.

Removes AllocateRWX, setWritable and setExecutable from sys::Memory and
standardizes on allocateMappedMemory / protectMappedMemory. The
allocate

[Support] Support NetBSD PaX MPROTECT in sys::Memory.

Removes AllocateRWX, setWritable and setExecutable from sys::Memory and
standardizes on allocateMappedMemory / protectMappedMemory. The
allocateMappedMemory method is updated to request full permissions for memory
blocks so that they can be marked executable later.

llvm-svn: 318464

show more ...

Don't try to use a non-existent header on FreeBSD/mips.

Reviewers: dim

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

llvm-svn: 316581

Implement AllocateRWX and ReleaseRWX for NetBSD

Summary:
NetBSD ships with PaX MPROTECT disallowing RWX mappings.
There is a solution to bypass this restriction with double mapping
RX (code) and RW

Implement AllocateRWX and ReleaseRWX for NetBSD

Summary:
NetBSD ships with PaX MPROTECT disallowing RWX mappings.
There is a solution to bypass this restriction with double mapping
RX (code) and RW (data) using mremap(2) MAP_REMAPDUP.
The initial mapping must be mmap(2)ed with protection:
PROT_MPROTECT(PROT_EXEC).

This functionality to bypass PaX MPROTECT appeared in NetBSD-7.99.72.

This patch fixes 20 failing tests:
- LLVM :: DebugInfo/debuglineinfo-macho.test
- LLVM :: DebugInfo/debuglineinfo.test
- LLVM :: ExecutionEngine/RuntimeDyld/Mips/ELF_Mips64r2N64_PIC_relocations.s
- LLVM :: ExecutionEngine/RuntimeDyld/Mips/ELF_N32_relocations.s
- LLVM :: ExecutionEngine/RuntimeDyld/Mips/ELF_N64R6_relocations.s
- LLVM :: ExecutionEngine/RuntimeDyld/Mips/ELF_O32R6_relocations.s
- LLVM :: ExecutionEngine/RuntimeDyld/Mips/ELF_O32_PIC_relocations.s
- LLVM :: ExecutionEngine/RuntimeDyld/X86/COFF_i386.s
- LLVM :: ExecutionEngine/RuntimeDyld/X86/COFF_x86_64.s
- LLVM :: ExecutionEngine/RuntimeDyld/X86/ELF-relaxed.s
- LLVM :: ExecutionEngine/RuntimeDyld/X86/ELF_STT_FILE.s
- LLVM :: ExecutionEngine/RuntimeDyld/X86/ELF_x64-64_PC8_relocations.s
- LLVM :: ExecutionEngine/RuntimeDyld/X86/ELF_x64-64_PIC_relocations.s
- LLVM :: ExecutionEngine/RuntimeDyld/X86/ELF_x86-64_PIC-small-relocations.s
- LLVM :: ExecutionEngine/RuntimeDyld/X86/ELF_x86-64_debug_frame.s
- LLVM :: ExecutionEngine/RuntimeDyld/X86/ELF_x86_64_StubBuf.s
- LLVM :: ExecutionEngine/RuntimeDyld/X86/MachO_empty_ehframe.s
- LLVM :: ExecutionEngine/RuntimeDyld/X86/MachO_i386_DynNoPIC_relocations.s
- LLVM :: ExecutionEngine/RuntimeDyld/X86/MachO_i386_eh_frame.s
- LLVM :: ExecutionEngine/RuntimeDyld/X86/MachO_x86-64_PIC_relocations.s

Sponsored by <The NetBSD Foundation>

Reviewers: joerg, lhames

Reviewed By: joerg

Subscribers: sdardis, llvm-commits, arichardson

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

llvm-svn: 305650

show more ...

Correct mprotect page boundries to round up end page. Fixes PR30905.

Summary:
Update the boundries for mprotect.
Patch by Andrew Adams. Fixes PR30905.

Reviewers: loladiro, andrew.w.kaylor, chandler

Correct mprotect page boundries to round up end page. Fixes PR30905.

Summary:
Update the boundries for mprotect.
Patch by Andrew Adams. Fixes PR30905.

Reviewers: loladiro, andrew.w.kaylor, chandlerc

Subscribers: abadams, llvm-commits

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

llvm-svn: 286032

show more ...

Deal with the (historic) MAP_ANONYMOUS vs MAP_ANON directly by using CPP
to check for the former, don't depend on (dangling) HAVE_MMAP_ANONYMOUS.

llvm-svn: 282925

Retire NEED_DEV_ZERO_FOR_MMAP. It should be needed only on outdated
systems. It wasn't even hooked up in cmake, so problems on such systems
would be visible with 3.9 release already.

llvm-svn: 282924

Fix Clang-tidy modernize-use-nullptr and modernize-use-override warnings; other minor fixes.

Differential revision: reviews.llvm.org/D16568

llvm-svn: 258831

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