We don't need to populate a string table, so we don't need to pre-parse the
remarks.
Split the bitstream2yaml and yaml2bitstream cases up so that we can avoid the
extra remark traversal in the bitstream2yaml case.
This kills the TODO.
Extend the llvm-dwp to support searching the DWOs that from relative path for the
case that build from remote building system(different comp_dir).
Reviewd By: dblaikie
Differential Revision: https://reviews.llvm.org/D133480
For now, we report nothing if the execution/dwo file is missing, which is confusing.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D133549
llvm-lipo crashes when trying to use inputs that contain bitcode asm instructions.
This happens when trying to create universal binaries for LLVM with LTO.
https://reviews.llvm.org/D118575 is a similar change that ran into this same issue, and I'm
mirroring the same change by registering the targets to fix this issue.
Reviewed By: alexander-shaposhnikov, keith
Differential Revision: https://reviews.llvm.org/D133729
Some compilers (like all the ones I've tried) seem to NVRO the
Expected<std::vector<unique_ptr>> but other ones (like some of the bots) seem
to not want to.
Change the return type to Error and pass in the vector as an output parameter
to try and fix things.
This adds llvm-remarkutil. This is intended to be a general tool for doing stuff
with/to remark files.
This patch gives it the following powers:
* `bitstream2yaml` - To convert bitstream remarks to YAML
* `yaml2bitstream` - To convert YAML remarks to bitstream remarks
These are both implemented as subcommands, like
`llvm-remarkutil bitstream2yaml <input_file> -o -`
I ran into an issue where I had some bitstream remarks coming from CI, and I
wanted to be able to do stuff with them (e.g. visualize them). But then I
noticed we didn't have any tooling for doing that, so I decided to write this
thing.
Being able to output YAML as a start seemed like a good idea, since it
would allow people to reuse any tooling they may have written based around YAML
remarks.
Hopefully it can grow into a more featureful remark utility. :)
Currently there are is an outstanding performance issue (see the TODO) with
the bitstream2yaml case. I decided that I'd keep the tool small to start with
and have the yaml2bitstream and bitstream2yaml cases be symmetric.
Also I moved the remarks documentation to its own header because it seems
a little out of place with "basic commands" and "developer tools"; it's
really kind of its own thing.
Differential Revision: https://reviews.llvm.org/D133646
I'm planning to deprecate and eventually remove llvm::empty.
I thought about replacing llvm::empty(x) with std::empty(x), but it
turns out that all uses can be converted to x.empty(). That is, no
use requires the ability of std::empty to accept C arrays and
std::initializer_list.
Differential Revision: https://reviews.llvm.org/D133677
64-bit atomics are used in llvm/ADT/Statistic.h, which means that users
of libLLVM.so might also have to link with libatomic. To avoid having
to special-case the library here, we simply add all `LLVM_SYSTEM_LIBS`
as public link dependencies to libLLVM.
This fixes a build failure on PowerPC 32-bit.
Reviewed By: beanz
Differential Revision: https://reviews.llvm.org/D132799
Replacing the following instances of UndefValue with PoisonValue, where the UndefValue is used as an arbitrary value:
- llvm/lib/CodeGen/WinEHPrepare.cpp
`demotePHIsOnFunclets`: RAUW arbitrary value for lingering uses of removed PHI nodes
- llvm/lib/Transforms/Utils/BasicBlockUtils.cpp
`FoldSingleEntryPHINodes`: Removes a self-referential single entry phi node.
- llvm/lib/Transforms/Utils/CallGraphUpdater.cpp
`finalize`: Remove all references to removed functions.
- llvm/lib/Transforms/Utils/ScalarEvolutionExpander.cpp
`cleanup`: the result is not used then the inserted instructions are removed.
- llvm/tools/bugpoint/CrashDebugger.cpp
`TestInts`: the program is cloned and instructions are removed to narrow down source of crash.
Differential Revision: https://reviews.llvm.org/D133640
Removes public bootstrap method that is not really necessary and not consistent with other platform API.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D132780
Supports dynamic VC runtime. It implements atexits handling which is required to load msvcrt.lib successfully. (the object file containing atexit symbol somehow resolves to static vc runtim symbols) It also default to dynamic vc runtime which tends to be more robust.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D132525
https://lab.llvm.org/buildbot#builders/56/builds/3201 failed with a link error being unable to initialize the disassembler. Oddly, this bot is the *only* bot which appears to have failed in this way. (A bunch sent warnings, but that appears to be spurious due to cmake rebuilds on incremental bots.) Why only polly would witness this is an excercise for the reader - because I have no clue.
llvm-exegesis is rather odd in the LLVM ecosystem in code is selectively compiled based on the native machine. LLVM is cross compiler by default, so this stands out as odd. It's also less then helpful when working on code for a target other than your native dev environment.
This change only changes the build setup. A later change will enable -march support to allow actual benchmarking under e.g. simulators in a cross compilation environment.
Differential Revision: https://reviews.llvm.org/D133150
It doesn't have a section header string table so add a vector to have
the strings and create name based on the program header type and the
index.
Differential Revision: https://reviews.llvm.org/D131290
"Z" was so named when we had both gABI ELFCOMPRESS_ZLIB and the legacy .zdebug support.
Now we have just one zlib format, we should use the more descriptive name.
The original implementation assumed dynamic libraries and so looked
only at the dynamic symbol table. Use the regular symbol table for
ET_REL files.
Differential Revision: https://reviews.llvm.org/D133448
LLVM contains a helpful function for getting the size of a C-style
array: `llvm::array_lengthof`. This is useful prior to C++17, but not as
helpful for C++17 or later: `std::size` already has support for C-style
arrays.
Change call sites to use `std::size` instead.
Differential Revision: https://reviews.llvm.org/D133429
Current implementation of registerModuleReference() function not only
"registers" module reference, but also clones referenced module
(inside loadClangModule()). That may lead to cloning the module with
incorrect options (registerModuleReference() examines module references
and additionally accumulates MaxDwarfVersion and accel tables info).
Since accumulated options may differ from the current values,
it is incorrect to clone modules before options are fully accumulated.
This patch separates "cloning" code from "registering" code. So,
that accumulating option is done in the "registering stage" and
"cloning" is done after all modules are registered and options accumulated.
It also adds a callback for loaded compile units which can be used for
D132755 and D132371(to allow doing options accumulation outside
of DWARFLinker).
Differential Revision: https://reviews.llvm.org/D133047
At least `ntdll` is using the undocumented version 2 unwind info, and opcode 6, which is already defined as `UOP_Epilog`.
Using `llvm-objdump --unwind` with `ntdll` would previously result in unreachable assertions because this code was missing from `getNumUsedSlots` and `getUnwindCodeTypeName`.
The slots of these codes comes from 57bfe47451/src/coreclr/inc/win64unwind.h (L51-L52) which I would assume is a good authoritative source.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D107655
add LLVM_PREFER_STATIC_ZSTD (default TRUE) cmake config flag
(compression test seems to fail for shared zstd on windows, note that zstd multithread is by default disabled in the static build so it may be a hidden variable)
propagate variable zstd_DIR in LLVMConfig.cmake.in
fix llvm-config CMakeLists.txt behavior for absolute libs windows
get zstd lib name
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D132870
This flag instructs dyld to make the segment read-only after fixups have
been performed.
I'm not sure why this flag is needed, as on macOS 13 beta at least,
__DATA_CONST is read-only even without this flag; but ld64 sets it as
well.
Differential Revision: https://reviews.llvm.org/D133010
This also modifies llvm-readobj to be more future-proof when printing
the guard FIDs table by calculating the entry size correctly according
to MS docs.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D132924
This section stores 32-bit `__TEXT` segment offsets of initializer
functions, and is used instead of `__mod_init_func` when chained fixups
are enabled.
Storing the offsets lets us avoid emitting fixups for the initializers.
Differential Revision: https://reviews.llvm.org/D132947
`getCPUStr()` fallsback to `getMCPU()`.
The only difference between `getCPUStr()` and `getMCPU()` is that
`getCPUStr()` handles `-mcpu=native`. That doesn't matter for this case.
This is just a simplification of the original code and it does not
change the functionality. So no new tests added.
Differential Revision: https://reviews.llvm.org/D132849
llvm-size falls back to printing in Berkeley format, if --format=darwin is specified and a non-Mach-O object has been provided. However, it does not print the input filename when it should:
Before -
(base) xgupta@archlinux ~/llvm/llvm-project/build (main*) $ llvm-size ~/hello.o --format=darwin
text data bss dec hex filename
291 0 0 291 123 %
After -
(base) xgupta@archlinux ~/llvm/llvm-project/build (main*) $ bin/llvm-size ~/hello.o --format=darwin
text data bss dec hex filename
291 0 0 291 123 /home/xgupta/hello.o
Fix#42316
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D132364
Current implementation promotes a non-cold function in the SampleFDO profile
into a hot function in the FDO profile. This is too aggressive. This patch
promotes a hot functions in the SampleFDO profile into a hot function, and a
warm function in SampleFDO into a warm function in FDO.
Differential Revision: https://reviews.llvm.org/D132601
This patch has the following changes:
(1) Handling of internal linkage functions (static functions)
Static functions in FDO have a prefix of source file name, while they do not
have one in SampleFDO. Current implementation does not handle this and we are
not updating the profile for static functions. This patch fixes this.
(2) Handling of -funique-internal-linakge-symbols
Again this is for the internal linkage functions. Option
-funique-internal-linakge-symbols can now be applied to both FDO and SampleFDO
compilation. When it is used, it demangles internal linkage function names and
adds a hash value as the postfix.
When both SampleFDO and FDO profiles use this option, or both
not use this option, changes in (1) should handle this.
Here we also handle when the SampleFDO profile using this option while FDO
profile not using this option, or vice versa.
There is one case where this patch won't work: If one of the profiles used
mangled name and the other does not. For example, if the SampleFDO profile
uses clang c-compiler and without -funique-internal-linakge-symbols, while
the FDO profile uses -funique-internal-linakge-symbols. The SampleFDO profile
contains unmangled names while the FDO profile contains mangled names. If
both profiles use c++ compiler, this won't happen. We think this use case
is rare and does not justify the effort to fix.
Differential Revision: https://reviews.llvm.org/D132600
1) We now use the count size in FDO as the main factor to deal with pre-inliner.
Currently we use the number of sample records in the SampleFDO profile. But
that only counts the top-level body sample records (not including the nested
call-sites). We are seeing some big functions not being updated because of
this. I think using the count size in FDO profile is more reasonable to judge if
the function is likely to be inlined to the callers in pre-inliner.
(2) We use getMaxCount in SampleFDO rather the HeadSample to determine if
if the function is hot in SampleFDO. This is in-sync with the logic
in the compiler (also HeadSample can be 0).
Differential Revision: https://reviews.llvm.org/D132602
MapperJITLinkMemoryManager combined with SharedMemoryMapper can be
used in place of EPCGenericJITLinkMemoryManager when running on top of
same physical memory. This commit enables it when --use-shared-memory is
passed.
Differential Revision: https://reviews.llvm.org/D132369
This option outputs the location, encoded value and target of chained
fixups, using the same format as `otool -dyld_info`.
This initial implementation only supports the DYLD_CHAINED_PTR_64 and
DYLD_CHAINED_PTR_64_OFFSET pointer encodings, which are used in x86_64
and arm64 userspace binaries.
When Apple's effort to upstream their chained fixups code continues,
we'll replace this code with the then-upstreamed code. But we need
something in the meantime for testing ld64.lld's chained fixups code.
Differential Revision: https://reviews.llvm.org/D132036
This patch replaces clamp idioms with std::clamp where the range is
obviously valid from the source code (that is, low <= high) to avoid
introducing undefined behavior.
MapperJITLinkMemoryManager has slab allocation. Combined with
InProcessMapper, it can replace InProcessMemoryManager.
It can also replace JITLinkSlabAllocator through the InProcessDeltaMapper
that adds an offset to the executor addresses for use in tests.
Differential Revision: https://reviews.llvm.org/D132315
Adds a pass ExpandLargeDivRem to expand div/rem instructions
with more than 128 bits into a loop computing that value.
As discussed on https://reviews.llvm.org/D120327, this approach has the advantage
that it is independent of the runtime library. This also helps the clang driver,
which otherwise would need to understand enough about the runtime library
to know whether to allow _BitInts with more than 128 bits.
Targets are still free to disable this pass and instead provide a faster
implementation in a runtime library.
Fixes https://github.com/llvm/llvm-project/issues/44994
Differential Revision: https://reviews.llvm.org/D126644
Jessica Paquette