We currently don't have any ABI tags in our dylib symbols, and this is
unlikely to change in the future. By diagnosing this we avoid
accidentally adding one through e.g. having `_LIBCPP_HIDE_FROM_ABI` on
an exported symbol.
https://github.com/llvm/llvm-project/pull/134787 unintentionally enabled
`--mmap-output-file` by default under LLD which caused the Windows-only
test `lld\test\ELF\link-open-file.test` to fail. This failure uncovered
what appears to be an inconsistency on Windows between
`createOnDiskBuffer` and `createInMemoryBuffer` with respect to `DELETE`
access for the output file.
The output file created by `createOnDiskBuffer` sets the flag
`OF_Delete` as part of `fs::TempFile::create` while the output file
created by `createInMemoryBuffer` sets `OF_None` under
`InMemoryBuffer::commit`.
The test `lld\test\ELF\link-open-file.test` ensures that if
`FILE_SHARE_DELETE` is _not_ specified for an output file that LLD is
expected to overwrite, LLD should fail. This only happens if: "the file
or device has been opened for delete access" which is only done for
`fs::TempFile::create`.
See
https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilew#FILE_SHARE_DELETE.
Therefore, I propose setting `OF_Delete` for `InMemoryBuffer::commit`'s
call to `openFileForWrite` to stay consistent with
`fs::TempFile::create`.
Utilize the new extensions to the LLVM Offloading API to extend to
llvm-objdump to handle dumping fatbin offload bundles generated by HIP.
This extension to llvm-objdump adds the option --offload-fatbin.
Specifying this option will take the input object/executable and extract
all offload fatbin bundle entries into distinct code object files with
names reflecting the source file name combined with the Bundle Entry ID.
Users can also use the --arch-name option to filter offload fatbin
bundle entries by their target triple.
---------
Co-authored-by: dsalinas <dsalinas@MKM-L1-DSALINAS.amd.com>
Static analysis flagged the unconditional access of getExternalSource().
We don't initialize ExternalSource during construction but via
setExternalSource(). If this is not set it will violate the invariant
covered by the assert.
This fixes an issue reported by the sanitizer with the following error
message:
`copy_constructor_call: IndexOpts` is passed by value as a parameter to`
clang::index::IndexingOptions::IndexingOptions` instead of being moved.
Only the latter part of optimizeIncrementingWhile requires a constant
first operand and so the initial bailout code is preventing the obvious
whilele(X,MAX_INT) -> splat(true) combine.
Currently coroutine promises are modeled as allocas. This is problematic
because other middle-end passes will assume promise dead after coroutine
suspend, leading to misoptimizations.
I propose the front ends remain free to emit and use allocas to model
coro promise. At CoroEarly, we will replace all uses of promise alloca
with `coro.promise`. Non coroutine passes should only access promise
through `coro.promise`. Then at CoroSplit, we will lower `coro.promise`
back to promise alloca again. So that it will be correctly collected
into coro frame. Note that we do not have to bother maintainers of other
middle-end passes.
Fix#105595
This enables file_specific_compile_options to take precedence over
ARG_COMPILE_FLAGS. For example, if we add -fno-slp-vectorize to
COMPILE_OPTIONS of a file, the behavior changes as follows:
* Before this PR: -fno-slp-vectorize is overwritten by -O3, resulting in
SLP vectorizer remaining enabled.
* After this PR: -fno-slp-vectorize overwrites -O3, effectively
disabling SLP vectorizer.
The previous method splits vector data into two halves. shuffle_vector
concatenates the two results into a vector data of original size. This
PR eliminates the use of shuffle_vector.
The "target-features" function attribute is not currently considered
when adding vscale_range to a function. When +sve/+sme are pushed onto
functions with "#pragma attribute push(+sve/+sme)", the function
potentially misses out on optimizations that rely on vscale_range being
present.
For the majority of cases, this is a neutral or positive change.
There are even testcases that greatly benefit from it, but some regressions are possible.
There is #140040 for GlobalISel that'd need to be fixed but it's only a one instruction regression and I think it can be fixed later.
Solves #64591
Directive was implemented in c87bd2d8eb to support lazy binding and is
emitted for vector PCS functions. It's specific to ELF but is currently
emitted for all binary formats and crashing on non-ELF targets.
Fixes#138260
---------
Co-authored-by: Cullen Rhodes <cullen.rhodes@arm.com>
For a dependent variable template specialization, we don't build a
dependent Decl node or a DeclRefExpr to represent it. Instead, we
preserve the UnresolvedLookupExpr until instantiation.
However, this approach isn't ideal for constraint normalization. We
consider the qualifier during profiling, but since that's based on the
written code, it can introduce confusing differences, even when the
expressions resolve to the same declaration.
This change ensures that, if possible, we profile the resolved
declaration instead of its qualifier. For expressions that resolve to
more than one declarations, we still profile its qualifier, as otherwise
it would make us depend on the order of lookup results.
Fixes https://github.com/llvm/llvm-project/issues/139476
This fully annotates the Cursor class, resolving 95 strict typing errors
as the next step towards #76664
These changes are a superset of the typing annotation changes from
#120590
Add a few library functions that were not previously registered to the
`CDLL` object. The current behavior relied on the default `restype` to
work.
Add a test to check that all used library functions are properly
registered.
The MS bit-field packing ABI depends on the storage size of the type of
being placed in the bit-field. This PR addresses a number of cases in
llvm where the storage type has lead to suboptimal packing.
When the memory operand of MOVEM instruction has an addressing mode of
pre-decrement, the move mask should be reversed.
This patch fixes it by creating a new asm operand with a different
encoding method.
Reported by @petmac
This commit introduces the `import-structs-as-literals` option to the
MLIR import. This ensures that all struct types are imported as literal
structs, even when they are named in LLVM IR.
