Some object files produced by Mirosoft tools contain sections whose name field
is not fully null-padded at the end. Microsoft's dumpbin is able to print the
section name correctly, but this causes parsing errors with LLVM tools.
So far, this issue only seems to happen when the section name is longer than 8
bytes. In this case, the section name field contains a slash (/) followed by the
offset into the string table, but the name field is not fully null-padded at the
end.
Reviewed By: mstorsjo
Differential Revision: https://reviews.llvm.org/D127369
In the case you pass multiple universal binaries to llvm-cov, assume
that if only 1 architecture is passed, it should be used for all the
passed binaries.
This makes it easier to use multiple multi-arch binaries, since it's
likely very rare that your architectures mismatch significantly if you
also have multiple binaries in a single llvm-cov invocation. If the
architecture is invalid for any of the passed binaries, it will still
fail later.
Differential Revision: https://reviews.llvm.org/D121667
UNIX03 conformance requires utilities to flush stdout before exiting and raise
an error if writing fails. Flushing already happens on a call to exit
and thus automatically on a return from main. Write failure is then
detected by LLVM's default SIGPIPE handler. The handler already exits with
a non-zero code, but conformance additionally requires an error message.
* The yaml input is inlined into the test file.
* Unnecessary members and fields are removed.
Reviewed By: thieta
Differential Revision: https://reviews.llvm.org/D127235
After D126425 was submitted, hans@ observed that MSVC's ml.exe doesn't
care about the file's extension at all. Now, we check if the file exists
to determine whether an input filename is a valid assembly file.
To keep things consistent with clang-cl and lld-link, llvm-ml will treat
everything that's not a flag as a filename.
Reviewed By: hans
Differential Revision: https://reviews.llvm.org/D126931
The intention is that these should never have undef operands. It turns
out the restriction the verifier enforces is too lax. The verifier
enforces that registers without a register class cannot be undef, but
it's valid to use a register with a register class and type. The
verifier needs to change to be based on the opcode.
MIR support is totally unusable for AMDGPU without this, since the set
of reserved registers is set from fields here.
Add a clone method to MachineFunctionInfo. This is a subtle variant of
the copy constructor that is required if there are any MIR constructs
that use pointers. Specifically, at minimum fields that reference
MachineBasicBlocks or the MachineFunction need to be adjusted to the
values in the new function.
Use the query that doesn't assert if TracksLiveness isn't set, which
needs to always be available. We also need to start printing liveins
regardless of TracksLiveness.
Some libraries (e.g., arm64rt.lib) from the Windows WDK (version 10.0.22000.0)
contain an undocumented special member '/<ECSYMBOLS>/'. This causes llvm-lib to
fail with the following error:
"truncated or malformed archive (long name offset characters after the '/' are
not all decimal numbers: '<ECSYMBOLS>/' for archive member header at offset 162)"
The '/<ECSYMBOLS>/' member does not seem to be documented anywhere, but might be
related to the ARM64EC ABI Microsoft announced last year.
https://blogs.windows.com/windowsdeveloper/2021/06/28/announcing-arm64ec-building-native-and-interoperable-apps-for-windows-11-on-arm/
Reviewed By: thieta, thakis
Differential Revision: https://reviews.llvm.org/D127135
This patch adds support for parsing the DXIL part data into the
ObjectYAML tooling.
The DXIL part has additional headers describing the shader and bitcode
data and stores serialized bitcode after the headers.
Depends on D124945
Reviewed By: kuhar
Differential Revision: https://reviews.llvm.org/D126795
Currently, only custom sections can be selected by operations that use section
names, because only custom sections have explicit names (whereas known sections
have names defined by the spec and only use their indices in the binary format).
This CL makes objdopy use the spec-defined names for these sections, allowing
them to be used in operations such as dumping and removal.
This is a prerequisite for fixing
https://github.com/emscripten-core/emscripten/issues/13084
Differential Revision: https://reviews.llvm.org/D126509
This change finishes fleshing out the ObjectYAML tools to support
converting DXContainer files into yaml representations.
Depends on D124944
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D124945
Using the pointer type analysis we can re-constitute typed pointers and
populate the correct types in the bitcasts throughout the IR.
This doesn't yet handle all cases, but this should be illustrative as
to the dirction and feasability of
the solution.
Reviewed By: pete
Differential Revision: https://reviews.llvm.org/D122270
This patch adds an llvm-driver multicall tool that can combine multiple
LLVM-based tools. The build infrastructure is enabled for a tool by
adding the GENERATE_DRIVER option to the add_llvm_executable CMake
call, and changing the tool's main function to a canonicalized
tool_name_main format (i.e. llvm_ar_main, clang_main, etc...).
As currently implemented llvm-driver contains dsymutil, llvm-ar,
llvm-cxxfilt, llvm-objcopy, and clang (if clang is included in the
build).
llvm-driver can be enabled from builds by setting
LLVM_TOOL_LLVM_DRIVER_BUILD=On.
There are several limitations in the current implementation, which can
be addressed in subsequent patches:
(1) the multicall binary cannot currently properly handle
multi-dispatch tools. This means symlinking llvm-ranlib to llvm-driver
will not properly result in llvm-ar's main being called.
(2) the multicall binary cannot be comprised of tools containing
conflicting cl::opt options as the global cl::opt option list cannot
contain duplicates.
These limitations can be addressed in subsequent patches.
Differential revision: https://reviews.llvm.org/D109977
This enabled opaque pointers by default in LLVM. The effect of this
is twofold:
* If IR that contains *neither* explicit ptr nor %T* types is passed
to tools, we will now use opaque pointer mode, unless
-opaque-pointers=0 has been explicitly passed.
* Users of LLVM as a library will now default to opaque pointers.
It is possible to opt-out by calling setOpaquePointers(false) on
LLVMContext.
A cmake option to toggle this default will not be provided. Frontends
or other tools that want to (temporarily) keep using typed pointers
should disable opaque pointers via LLVMContext.
Differential Revision: https://reviews.llvm.org/D126689
This change prints out the segment information in the raw profile in
YAML format for testing. Since we don't capture build ids yet, we print
out <None> for now.
Reviewed By: tejohnson
Differential Revision: https://reviews.llvm.org/D126840
Update the YAML format print out of the profile to include a summary
instead of displaying the headers in the raw file buffer. This allows us
to release the raw buffer early saving memory.
Reviewed By: tejohnson
Differential Revision: https://reviews.llvm.org/D126834
Support the pattern where a test file uses multiple prefixes per run line:
one prefix that is unique to the run line, and additional prefixes that are
common with other run lines.
Decide on a per-function basis which prefix(es) to emit, based on which run
lines have the same output.
Move the renaming of vregs earlier, so that we can compare the output as it
would actually be printed in check lines.
Differential Revision: https://reviews.llvm.org/D126411
This patch adds a the first bits of support for a yaml representation
of dxcontainer files.
Since the YAML representation's primary purpose is testing
infrastructure, the yaml representation supports both verbose and a
more friendly format by making computable sizes and offsets optional.
If provided they are validated to be correct, otherwise they are
computed on the fly during emission.
As I expand the format I'll be able to make more size fields optional,
and I will continue to make the format easier to work with.
Depends on D124804
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D124944
I'm a bit confused by what's actually stored for the allocation
hints. The MIR parser only handles the "simple" case where there's a
single hint. I don't really understand the assertion in
clearSimpleHint, or under what circumstances there are multiple hint
registers.
znver1/2 models were incorrectly modelling the latency/throughput/uops and znver1 ymm variants also require double pumping.
Now matches what I can decipher from the AMD SoG, Agner and instlatx64 numbers vs the llvm-exegesis report provided by @fabian-r
znver1 ymm variants of VPMOVSX**/VPMOVZX** instructions require double pumping.
Now matches AMD SoG, Agner and instlatx64 numbers.
Thanks to @fabian-r for the report
znver1/2 models were incorrectly modelling the fpupipe (should be pipe2 for shift-by-scalar-amount and pipe1 for shift-by-element-amount) and znver1 ymm variants also require double pumping.
Now matches AMD SoG, Agner and instlatx64 numbers.
Thanks to @fabian-r for the report
This is scoped to autogenerated tests.
The goal is to support having each RUN line specify a list of
check-prefixes where one can specify potentially redundant prefixes. For example,
for X86, if one specified prefixes for both AVX1 and AVX2, and the codegen happened to
match today, one of the prefixes would be used and the onther one not.
If the unused prefix were dropped, and later, codegen differences were
introduced, one would have to go figure out where to add what prefix
(paraphrasing
https://lists.llvm.org/pipermail/llvm-dev/2021-February/148326.html)
To avoid getting errors due to unused prefixes, whole directories can be
opted out (as discussed on that thread), but that means that tests that
aren't autogenerated in such directories could have undetected unused
prefix bugs.
This patch proposes an alternative that both avoids the above, dir-level
optout, and supports the main autogen scenario discussed first. The autogen
tool appends at the end of the test file the list of unused prefixes,
together with a note explaining that is the case. Each prefix is set up
to always pass.
This way, unexpected unused prefixes are easily discoverable, and
expected cases "just work".
Differential Revision: https://reviews.llvm.org/D124306
Even though MASM files typically have the .asm extension, there are some
use cases [0] where they have the .S extension. MSVC ml assembles such
files with no problems, so llvm-ml should as well.
Additionally, fix the implementation of the /Ta flag and add a test for
it.
[0]: https://crrev.com/c/3668287
Reviewed By: epastor
Differential Revision: https://reviews.llvm.org/D126425
Extend the Frame struct to hold the symbol name if requested
when a RawMemProfReader object is constructed. This change updates the
tests and removes the need to pass --debug to obtain the mapping from
GUID to symbol names.
Reviewed By: tejohnson
Differential Revision: https://reviews.llvm.org/D126344
Rely on lit substitution to provide the path to llvm-windres instead
of redundantly calling which(1) with the subtituted absolute path.
This fixes test failure on the happy systems without which(1) installed.
Differential Revision: https://reviews.llvm.org/D126366
When the single branch target of a block has been removed try updating
it to target a block that is kept (by scanning forward in the sequence)
instead of replacing the branch with a return instruction. Doing so
reduces the risk of breaking loop structures meaning that when the loop
is 'interesting' these reductions should have more blocks eliminated.
Differential Revision: https://reviews.llvm.org/D125766
Currently, llvm-symbolizer doesn't like to parse .debug_info in order to
show the line info for global variables. addr2line does this. In the
future, I'm looking to migrate AddressSanitizer off of internal metadata
over to using debuginfo, and this is predicated on being able to get the
line info for global variables.
This patch adds the requisite support for getting the line info from the
.debug_info section for symbolizing global variables. This only happens
when you ask for a global variable to be symbolized as data.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D123538
I had initially assumed this was the problem with
https://github.com/llvm/llvm-project/issues/55271#issuecomment-1133426243
But it turns out that was a simpler issue. This patch is still
more correct than what we were doing before so figured I'd submit
it anyway.
No test case because I'm not sure how to get an undef around
until expansion.
Looking at the test deltas I wonder if it be valid to combine
(sext_inreg (freeze (aextload X))) -> (freeze (sextload X)).
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D126175
Previously the error message didn't include the failing path, which made
it hard to tell what went wrong.
Differential Revision: https://reviews.llvm.org/D121665
When creating an archive, llvm-ar looks at the host to determine the
archive format to use, on Apple platforms this means it uses the
K_DARWIN format. K_DARWIN is _virtually_ equivalent to K_BSD, expect for
some very slight differences around padding, timestamps in deterministic
mode, and 64 bit formats. When updating an archive using llvm-ar, or
llvm-objcopy, Archive would try to determine the kind, but it was not
possible to get K_DARWIN in the initialization of the archive, because
they're virtually inciting usable from K_BSD, especially since the
slight differences only apply in very specific cases. This leads to
linker failures when the alignment workaround is not applied to an
archive copied with llvm-objcopy. This change teaches Archive to infer
the K_DARWIN type in the cases where it's possible and the first object
in the archive is a macho object. This avoids using the host triple to
determine this to not affect cross compiling.
Ideally we would eliminate the separate K_DARWIN type entirely since
it's not a truly separate archive type, but then we'd have to force the
macho workarounds on the BSD format generally. This might be acceptable
but then it would be unclear how to handle this case without forcing the
K_DARWIN64 format on all BSD users:
```
if (LastOffset >= Sym64Threshold) {
if (Kind == object::Archive::K_DARWIN)
Kind = object::Archive::K_DARWIN64;
else
Kind = object::Archive::K_GNU64;
}
```
The logic used to determine if the object is macho is derived from the
logic llvm-ar uses.
Previous context:
- 111cd669e90e5b2132187d36f8b141b11a671a8b
- 23a76be5adcaa768ba538f8a4514a7afccf61988
Differential Revision: https://reviews.llvm.org/D124895
