DXContainers contain a feature flag part, which stores a bitfield used
to denote what underlying hardware features the shader requires. This
change adds feature flags to the DXContainer YAML tooling to enable
testing generating feature flags during HLSL code generation.
Depends on D133980
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D134315
This patch refactors some of the DXContainer Object and YAML code to
make it easier to add more part parsing.
DXContainer has a whole bunch of constant values, so I've added a
DXContainerConstants.def file which will grow with constant
definitions, but starts with just part identifiers. I've also added a
utility to parse the part magic string into an enum, and converted the
code to use that utility and the enum instead of the part literal
string.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D133980
This patch removes the dependency to the legacy pass manager when
building llvm-stress.
Instead of setting up a pass manager at all we just run verifyModule()
to check that the generated IR satisfies the verifier, and then
we use Module::print() to output the IR. No need to setup passes and
populating a pass manager since we aren't doing anything more fancy
than that.
Reviewed By: aeubanks
Differential Revision: https://reviews.llvm.org/D134802
This adds an `instruction-count` command to llvm-remarkutil.
```
llvm-remarkutil instruction-count --parser=<bitstream|yaml> <file>
```
This will, for now, only print out asm-printer `InstructionCount` remarks.
Frequently I need to find out things like "what are the top 10 largest
functions" in a given project.
This makes it so we can find that information quickly and easily from any
format of remarks.
I chose a CSV because I usually want to stick these into a spreadsheet, and
the data is two-dimensional.
In the future, we may want to change this to another format if we add more
complicated data.
Differential Revision: https://reviews.llvm.org/D134765
This creates a library for fetching debug info by build ID, whether
locally or remotely via debuginfod. The functionality was refactored
out of existing code in the Symboliize library. Existing utilities
were refactored to use this library.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D132504
Interestingly, MathExtras.h doesn't use <cmath> declaration, so move it out of
that header and include it when needed.
No functional change intended, but there's no longer a transitive include
fromMathExtras.h to cmath.
This class was used for testing JITLink with -noexec option and
also included slab allocation support. Its functionality has been
replaced with InProcessDeltaMapper and MapperJITLinkMemoryManager.
Differential Revision: https://reviews.llvm.org/D134781
llvm::dwarfutil::ObjFileAddressMap::relocateIndexedAddr() does not
read address value. The relocateIndexedAddr() should not relocate
the address as the linked binary has already resolved relocations.
But it should read the value. This patch adds the reading value
of the address.
Differential Revision: https://reviews.llvm.org/D133324
Enable registration of multiple exegesis targets at once. Use idiomatic approach to defining target select macros, but leave code in the llvm-mca sub-directories for now.
This is a stepping stone towards allowing llvm-exegesis benchmarking via simulator or testing in non-target dependent tests.
Differential Revision: https://reviews.llvm.org/D133605
We were using the native triple to parse the benchmarks. Use the triple
from the benchmarks file.
Right now this still only allows analyzing files produced by the current
target until D133605 is in.
This also makes the `Analysis` class much less ad-hoc.
Differential Revision: https://reviews.llvm.org/D133697
There could be comma in one perf file path, since at this point it only support one file as input, there is no need for the `llvm:🆑:MiscFlags::CommaSeparated` option.
Reviewed By: hoy, wenlei
Differential Revision: https://reviews.llvm.org/D134287
Without this patch, the assertion triggers below on the test case,
because we are using different oracles for the verification.
Assertion failed: (Targets == NoChunksCounter.count() && "number of chunks changes when reducing"), function runDeltaPass, file Delta.cpp, line 272.
Summary:
according nm in AIX OS , https://www.ibm.com/docs/en/aix/7.2?topic=n-nm-command
In AIX OS, The default is to process 32-bit object files (ignore 64-bit objects). The mode can also be set with the OBJECT_MODE environment variable. For example, OBJECT_MODE=64 causes nm to process any 64-bit objects and ignore 32-bit objects. The -X flag overrides the OBJECT_MODE variable.
In non AIX OS. The default is to process all support object files. and not support the OBJECT_MODE environment variable.
Reviewers: James Henderson
Differential Revision: https://reviews.llvm.org/D132494
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
Currently, DWARFLinker determines the target DWARF version internally.
It examines incoming object files, detects maximal
DWARF version and uses that version for the output file.
This patch allows explicitly setting output DWARF version by the consumer
of DWARFLinker. So that DWARFLinker uses a specified version instead
of autodetected one. It allows consumers to use different logic for
setting the target DWARF version. f.e. instead of the maximally used version
someone could set a higher version to convert from DWARFv4 to DWARFv5
(This possibility is not supported yet, but it would be good if
the interface will support it). Or another variant is to set the target
version through the command line. In this patch, the autodetection is moved
into the consumers(DwarfLinkerForBinary.cpp, DebugInfoLinker.cpp).
Differential Revision: https://reviews.llvm.org/D132755
When .gnu.version_r is empty (allowed by readelf but warned by objdump),
llvm-objdump -p may decode the next section as .gnu.version_r and may crash due
to out-of-bounds C string reference. ELFFile<ELFT>::getVersionDependencies
handles 0-entry .gnu.version_r gracefully. Just use it.
Fix https://github.com/llvm/llvm-project/issues/57707
Differential Revision: https://reviews.llvm.org/D133751
Also skip dead defs when looking for a previous vreg with the same
class. This helps avoid some mid-reduction verifier errors when
LiveIntervals computation starts introducing dead flags everywhere.
A simple sed doing these substitutions:
- `${LLVM_BINARY_DIR}/\$\{CMAKE_CFG_INTDIR}/lib(${LLVM_LIBDIR_SUFFIX})?\>` -> `${LLVM_LIBRARY_DIR}`
- `${LLVM_BINARY_DIR}/\$\{CMAKE_CFG_INTDIR}/bin\>` -> `${LLVM_TOOLS_BINARY_DIR}`
where `\>` means "word boundary".
The only manual modifications were reverting changes in
- `compiler-rt/cmake/Modules/CompilerRTUtils.cmake`
because these were "entry points" where we wanted to tread carefully not not introduce a "loop" which would end with an undefined variable being expanded to nothing.
There are many more occurrences without `CMAKE_CFG_INTDIR`, but those are left for D132316 as they have proved somewhat tricky to fix.
This hopefully increases readability overall, and also decreases the usages of `LLVM_LIBDIR_SUFFIX`, preparing us for D130586.
Reviewed By: sebastian-ne
Differential Revision: https://reviews.llvm.org/D133828
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
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
Alex Brachet