As a follow up of the bad alloc handler patch, this patch introduces nullptr checks on pointers returned from the
malloc/realloc/calloc functions. In addition some memory size assignments are moved behind the allocation
of the corresponding memory to fulfill exception safe memory management (RAII).
patch by Klaus Kretzschmar
Differential Revision: https://reviews.llvm.org/D35414
llvm-svn: 308576
Split insertCSRSpillsAndRestores into insertCSRSaves + insertCSRRestores.
This is mostly useful for future shrink-wrapping improvements where we
want to save / restore a specific part of the CSRs in a specific block.
Differential Revision: https://reviews.llvm.org/D35644
llvm-svn: 308573
As discussed on llvm-dev I've implemented the first basic steps towards
llvm-objcopy/llvm-objtool (name pending).
This change adds the ability to copy (without modification) 64-bit
little endian ELF executables that have SHT_PROGBITS, SHT_NOBITS,
SHT_NULL and SHT_STRTAB sections.
Patch by Jake Ehrlich
Differential Revision: https://reviews.llvm.org/D33964
llvm-svn: 308559
Add optimization remarks support to the PrologueEpilogueInserter. For
now, emit the stack size as an analysis remark, but more additions wrt
shrink-wrapping may be added.
https://reviews.llvm.org/D35645
llvm-svn: 308556
Make doSpillCalleeSavedRegs a member function, instead of passing most
of the members of PEI as arguments.
Differential Revision: https://reviews.llvm.org/D35642
llvm-svn: 308555
Split insertCSRSpillsAndRestores into insertCSRSaves + insertCSRRestores.
This is mostly useful for future shrink-wrapping improvements where we
want to save / restore a specific part of the CSRs in a specific block.
Differential Revision: https://reviews.llvm.org/D35644
llvm-svn: 308554
The optional external function callbacks have to be exported in order
for them to be called. The test was failing because libFuzzer wasn't
calling LLVMFuzzerInitialize.
We can reconsider if this is the best way to mark these optional
callbacks exported later.
llvm-svn: 308548
This changes DwarfContext to delegate to DwarfObject instead of having
pure virtual methods.
With this DwarfContextInMemory is replaced with an implementation of
DwarfObject that is local to a .cpp file.
llvm-svn: 308543
The Args field of the remark which consists of a list of mappings in YAML is
translated into a list of (small) dicts on Python. An empty dict is 280 bytes
on my system so we can save memory by using a tuple of tuples instead.
Making a tuple of tuples rather than a list of tuples allows Args to be shared
with the key of the remark. This is actually an even greater saving. (Keys
are alive throughout the entire run in all_remarks.)
Here are a few opt-stats runs with different input sizes while measuring heap
usage with heapy. Avg remark size is simply estimated as
heap-size / # of remarks:
| # of files | 60 | 114 | 308 | 605 | 1370 |
| # of remarks | 20K | 37K | 146K | 180K | 640K |
| total file size (MB) | 22 | 51 | 219 | 202 | 1034 |
|------------------------+------+------+------+------+------|
| Avg remark size before | 4339 | 4792 | 4761 | 4096 | 4607 |
| Avg remark size after | 3446 | 3641 | 3567 | 3146 | 3347 |
| Rate | 0.79 | 0.76 | 0.75 | 0.77 | 0.73 |
Differential Revision: https://reviews.llvm.org/D35611
llvm-svn: 308538
If heapy is installed print the "average" in-memory remark size. This is
estimated by dividing the total heap size by the number of unique remarks.
llvm-svn: 308537
The observation is that we have a lot of similar remarks with lots of
identical strings (e.g. file paths, text from the remark). Storing a copy of
each of those strings in memory is wasteful. This makes all the strings in
the remark interned which maintains a single immutable instance that is
referenced everywhere.
I get an average 20% heap size reduction with this but it's possible that this
varies with the typical length of the file paths used. (I used heapy to
report the heap size.) Runtime is same or a tiny bit better.
| # of files | 60 | 114 | 308 | 605 | 1370 |
| # of remarks | 20K | 37K | 146K | 180K | 640K |
| total file size (MB) | 22 | 51 | 219 | 202 | 1034 |
|-----------------------+------+------+------+------+------|
| Heap size before (MB) | 106 | 226 | 894 | 934 | 3573 |
| Heap size after | 86 | 179 | 694 | 739 | 2798 |
| Rate | 0.81 | 0.79 | 0.78 | 0.79 | 0.78 |
|-----------------------+------+------+------+------+------|
| Average remark size | 4.30 | 4.84 | 4.75 | 4.11 | 4.37 |
| Mem2disk ratio | 3.91 | 3.51 | 3.17 | 3.66 | 2.71 |
Differential Revision: https://reviews.llvm.org/D35534
llvm-svn: 308536
This will allow eliminating the duplication of the names, and allow adding
extra information such as signatures in a future commit.
Differential Revision: https://reviews.llvm.org/D35522
llvm-svn: 308531
This change adds basic support for program headers.
I need to do some testing which requires generating program headers but
I can't use ld.lld or clang to produce programs that have headers. I'd
also like to test some strange things that those programs may never
produce.
Patch by Jake Ehrlich
Differential Revision: https://reviews.llvm.org/D35276
llvm-svn: 308520
This generalizes an existing fix from ELF to MachO and COFF.
Test that an ADRP to a local symbol whose offset is known at assembly
time still produces relocations, both for MachO and COFF. Test that
an ADRP without a @page modifier on MachO fails (previously it
didn't).
Differential Revision: https://reviews.llvm.org/D35544
llvm-svn: 308518
Summary:
GetSVN.cmake currently takes one or two pairs of <source directory path,
name>, then attempts to get the remote repository URL and source control
revision of the repositories at those one or two paths.
It takes two pairs in order for Clang to get the revision of both
itself, and its dependency LLVM.
For projects that rely upon both LLVM and Clang (Apple's Swift is one
example, but there are others), GetSVN.cmake is used to fetch *three*
revisions: Swift, Clang, and LLVM.
To support this use case, change GetSVN.cmake: instead of taking one or
two pairs (specified via `FIRST_SOURCE_DIR`/`FIRST_NAME`, have it take a list
of pairs (`SOURCE_DIRS`/`NAMES`).
In order to allow Clang to migrate, have GetSVN.cmake support both sets
of arguments for now. The old arguments can be removed once Clang begins
using the new arguments, and Swift can follow when it updates its
copy of LLVM.
Test Plan:
1. Perform a clean build of Clang, verify that `clang --version` still
prints the correct LLVM and Clang revision information.
2. Modify Clang's CMake to use the new arguments, then perform another
clean build. `clang --version` should still print the correct
revision information.
Reviewers: jordan_rose, beanz, probinson
Subscribers: echristo, chapuni, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D35132
llvm-svn: 308507
If the LowerTypeTests pass decides to add a function to a jump
table for CFI, it will add its name to the set cfiFunctionDefs,
which among other things will cause the function to be renamed in
the ThinLTO backend.
One other thing that we must do with such functions is to not
internalize them, because the jump table in the full LTO object will
contain a reference to the actual function body in the ThinLTO object.
This patch handles that by ensuring that we export any functions
whose names appear in the cfiFunctionDefs set.
Fixes PR33831.
Differential Revision: https://reviews.llvm.org/D35605
llvm-svn: 308504
Shared-library build on Solaris requires --whole-archive to be specified (option accepted by all available linkers).
At the same time, --version-script can not be handled by Solaris-ld, so it should be skipped.
-M is of no use here, since there is no syntax in Solaris-ld mapfiles that allows to version all global symbols,
not just the named ones (at least this is my impression from digging deep into the docs).
Patch by Fedor Sergeev <fedor.sergeev@oracle.com>
llvm-svn: 308490
It was warning like:
../llvm-project/llvm/lib/Support/ErrorHandling.cpp:172:51: warning:
ignoring return value of ‘ssize_t write(int, const void*, size_t)’,
declared with attribute warn_unused_result [-Wunused-result]
(void)::write(2, OOMMessage, strlen(OOMMessage));
Work around the warning by storing the return value in a variable and
casting that to void instead. We already did this for the other write()
call in this file.
llvm-svn: 308483
Describe:
+ Exact tablegen command and how to get it
+ tablegen command debug option for subtarget generation
+ Use of schedcover.py on the debug output to determine coverage
Differential Revision: https://reviews.llvm.org/D35058
llvm-svn: 308476
Kostya Serebryany