In preparation for eanbling 64bit support in LLDB switching to use llvm::formatv
instead of format MACROs.
Reviewed By: labath, JDevlieghere
Differential Revision: https://reviews.llvm.org/D139955
Local info is supposed to be emitted in the start of every function.
When there are locals, `.local` section should be present, and we emit
local info according to the section.
If there is no locals, empty local info should be emitted. This empty
local info is emitted whenever a first instruction is emitted within a
function without encountering a `.local` section. If there is no
instruction, `end_function` pseudo instruction should be present and the
empty local info will be emitted when parsing the pseudo instruction.
The following assembly is malformed because the function `test` doesn't
have an `end_function` at the end, and the parser doesn't end up
emitting the empty local info needed. But currently we don't error out
and silently produce an invalid binary.
```
.functype test () -> ()
test:
```
This patch adds one extra state to the Wasm assembly parser,
`FunctionLabel` to detect whether a function label is parsed but not
ended properly when the next function starts or the file ends.
It is somewhat tricky to distinguish `FunctionLabel` and
`FunctionStart`, because it is not always possible to ensure the state
goes from `FunctionLabel` -> `FunctionStart`. `.functype` directive does
not seem to be mandated before a function label, in which case we don't
know if the label is a function at the time of parsing. But when we do
know the label is function, we would like to ensure it ends with an
`end_function` properly. Also we would like to error out when it does
not.
For example,
```
.functype test() -> ()
test:
```
We should error out for this because we know `test` is a function and it
doesn't end with an `end_function`. This PR fixes this.
```
test:
```
We don't error out for this because there is no info that `test` is a
function, so we don't know whether there should be an `end_function` or
not.
```
test:
.functype test() -> ()
```
We error out for this currently already, because we currently switch to
`FunctionStart` state when we first see `.functype` directive after its
label definition.
Fixes https://github.com/llvm/llvm-project/issues/57427.
Reviewed By: sbc100
Differential Revision: https://reviews.llvm.org/D141103
The template parameter is no longer needed after MutSparseTensorDescriptor
is implemented as a subclass of SparseTensorDescriptorImpl. The only purpose
for it was to enable SFINAE.
Reviewed By: bixia
Differential Revision: https://reviews.llvm.org/D141303
Currently, tsan's memory mappings include 4GB
for high app, 20GB for mid app, and 8GB for low
app. The high app and mid app mappings are
too small for large programs, especially if ASLR
entropy (mmap_rnd_bits) is set higher. The low app
region (for non-PIE) is too small for some of tcmalloc's
internal tests (this does not affect normal apps,
since tsan will replace malloc).
This CL increases the memory mappings to 4TB for
high app, 1.3TB for mid app, and 10TB for low app. Note
that tsan's 44-bit pointer compression/decompression imposes
a 16TB limit on the combined size of the app mappings, making
this set of mappings more or less maximal.
Differential Revision: https://reviews.llvm.org/D140923
The symbol file stores a raw pointer to the main object file's symbol
table. This pointer, however, can be freed, if ObjectFile::ClearSymtab
is ever called. This patch makes sure out pointer to the symbol file
is valid before using it.
This patch fixes:
mlir/lib/Dialect/Vector/Transforms/VectorDistribute.cpp:947:13:
error: variable 'distributedDim' set but not used
[-Werror,-Wunused-but-set-variable]
In https://reviews.llvm.org/D137982 we found that on Mach-O private
aliases could trigger an assert in lld when the aliasee was a
weak_def_can_be_hidden symbol.
This appears to be incorrect, and should be allowed in Mach-O.
Disallowing this behavior is also inconsistent with how ld64 handles
a private alias to weak_def_can_be_hidden symbols.
This patch removes the assert and tests that LLD handles such aliases
gracefully.
Reviewed By: #lld-macho, int3
Differential Revision: https://reviews.llvm.org/D141082
Instead of maintaining a separate valid flag for BaseReg, Use
BaseReg.isValid(). I think this is left over from an older
implementation that maintained a vector of base registers.
The other change is not do a speculative assignment to BaseOffset
that needs to be reverted. Only commit it after we do the check.
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D141153
They do not seem to be GFX10-specific anymore. Also renames the
corresponding feature.
Reviewed By: dp
Differential Revision: https://reviews.llvm.org/D141069
This patch adds runtime default initialization for polymorphic
dummy argument. The dynamic type might require default initialization
but not the declared type.
Reviewed By: jeanPerier, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D141278
When an array element is extracted from an unlimited polymorphic array, the
emboxing of this element has to retrive the type code and element size from
the initial array. This patch retrive this information through the extracted
type descriptor.
This situation can be found in code like:
```
subroutine sub1(a)
class(*) :: a(:)
select type (x=>a(1))
type is (integer)
x = 10
end select
end subroutine
```
Reviewed By: jeanPerier, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D141274
Summary:
There's some static checks on the library, we can't do offloading with
`libgomp` for OpenMP. This patch specifies the library for the tests to
avoid this breaking tests.
There have been multiple cases where range calculations were wrong
in the 1 bit case. Make sure we catch these by not specifying the
bit width explicitly, and letting the test framework pick it (which
will now always test 1 and 4 bits both).
Previously HWCAP_ATOMIC and others were being used before checking if
they were defined. This moves up all the ifndef checks to define these
macros if they are not yet defined.
Differential Revision: https://reviews.llvm.org/D141285
In case the distributed dim of the dest vector is also a dim of the src vector, each lane inserts a smaller part of the source vector. Otherwise, one lane inserts the entire src vector and the other lanes do nothing.
Differential Revision: https://reviews.llvm.org/D137953
In case of a distribution, only one lane inserts the scalar value. In case of a broadcast, every lane inserts the scalar.
Differential Revision: https://reviews.llvm.org/D137929
Ops such as `%1 = vector.extract %0[2] : vector<5x96xf32>`.
Distribute the source vector, then extract. In case of a 1d extract, rewrite to vector.extractelement.
Differential Revision: https://reviews.llvm.org/D137646
For a full range input, we would produce an empty range instead
of a full range. The change to the SMin.isNonNegative() branch is
an optimality fix, because we should account for the potentially
discarded SMin value in the IntMinIsPoison case.
Change TestUnaryOpExhaustive to test both 4 and 1 bits, to both
cover this specific case in unit tests, and make sure all other
unary operations deal with 1-bit inputs correctly.
Fixes https://github.com/llvm/llvm-project/issues/59887.
The test uses `size_t` but does not include a header defining it. Include
`<cstddef>` which provides `size_t`.
Differential Revision: https://reviews.llvm.org/D141284
_LIBCPP_HIDE_FROM_ABI (which is what _LIBCPP_INLINE_VISIBILITY is) uses
ABI tags to avoid ODR violations when linking together object files
compiled against different versions of libc++. However, pointer
authentication uses the mangled name of the function to sign the
function pointer in the vtable, which means that the ABI tag effectively
changes how the pointers are signed.
This leads to PAC failures when passing an object that holds one of these
pointers in its vtable across an ABI boundary: one side will sign the
pointer using one function mangling (with one ABI tag), and the other
side will authenticate the pointer expecting it to have a different
mangled name, which won't work.
To make sure this does not regress in the future, this patch also adds
a clang-query test to detect incorrect applications of _LIBCPP_HIDE_FROM_ABI.
Differential Revision: https://reviews.llvm.org/D140453
Add a test case where some ops of a reassociate-able expression are in
an earlier block.
This can appear in practice, e.g. when computing the final reduction
value after vectorization.
This is another step in aligning addTypeForStreamingSVE with addTypeForFixedLengthSVE,
which also improves code quality for extending loads and truncating stores.
Reviewed By: hassnaa-arm
Differential Revision: https://reviews.llvm.org/D141266
These are still disabled by default, but will work in ObjC code if you
enable the `-import-insertions` flag.
Completion requires ASTSignals to be available; before ASTSignals are
available, we will always use #include. Once they are available, the
behavior varies as follows:
- For source files, use #import if the ObjC language flag is enabled
- For header files:
- If the ObjC language flag is disabled, use #include
- If the header file contains any #imports, use #import
- If the header file references any ObjC decls, use #import
- Otherwise, use #include
IncludeFixer support is similar, but it does not rely upon ASTSignals,
instead it does the above checks excluding the scan for ObjC symbols.
Differential Revision: https://reviews.llvm.org/D139458
Preserve the alignment of the original atomicrmw, rather than using
the ABI alignment.
The same problem exists for loads, but that code is being removed
in D141277 anyway.
When building the flang runtime if LTO is enabled the archive file
contains LLVM IR rather than object code. Currently flang is not
LTO aware so cannot link this file to compiled Fortran code.
This patch disables LTO when building the flang runtime to avoid
this issue.
Differential Revision: https://reviews.llvm.org/D140016
This reverts commit 7370ff624d.
(and 47fb8ae2f9).
This commit broke the symbol type in import libraries generated
for mingw autoexported symbols, when the source files were built
with LTO. I'll commit a testcase that showcases this issue after
the revert.
This is the ARM equivalent of D141119, where we fold `and x, (csel 0, 1, cc)`
to `csel ZR, x, cc` if we know that x is 0/1 and for `or x, (csel 0, 1, cc)`
emit `csinc x, ZR, cc`. The or pattern gets recognized from a cmov under Arm.
Differential Revision: https://reviews.llvm.org/D141137
When establishing the correspondence between transform values and
payload operations or parameters, check that the latter are non-null and
report errors. This was previously allowed for exotic cases of partially
successfull transformations with "apply each" trait, but was dangerous.
The "apply each" implementation was reworked to remove the need for this
functionality, so this can now be hardned to avoid null pointer
dereferences.
Reviewed By: nicolasvasilache
Differential Revision: https://reviews.llvm.org/D141142
