{D144170} didn't go via the normal clang-format reviewers and we'd have pointed out that this list of options remains sorted.
Reviewed By: owenpan
Differential Revision: https://reviews.llvm.org/D147176
It appears we've been incorrectly stripping CV qualifiers when capturing `this` by value inside lambdas.
This patch simply removes the CV stripping code as discussed.
Closes https://github.com/llvm/llvm-project/issues/50866
Reviewed By: #clang-language-wg, cor3ntin, aaron.ballman
Differential Revision: https://reviews.llvm.org/D146168
Previously the check to just return MAX or MIN used the caclulated
number being the maximum absolute value. This was right in every case
except for an unsigned conversion being passed its maximum value with a
negative sign on the front. This should return -MAX, but was returning
just MAX.
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D147171
As discussed earlier in the [GitHub
issue](https://github.com/llvm/llvm-project/issues/59500), currently
LLVM generates invalid code when emulated TLS is used. There were
attempts to resolve this previously (D102527), but they were not merged
because the component owners raised concerns about emulated TLS
efficiency.
The current state of the art is that:
- OpenBSD team, which raised the initial issue, simply has [patches
downstream](https://github.com/openbsd/src/blob/a0747c9/gnu/llvm/llvm/lib/Target/RISCV/RISCVISelLowering.cpp#L2850-L2852).
- Our team, which raised the GH issue, has patches downstream as well.
We also do not use `malloc` or any [dynamic
allocations](https://github.com/llvm/llvm-project/issues/59500#issuecomment-1349046835)
with emulated TLS, so the concerns raised in the original issue does not
apply to us.
- GCC compatibility is broken, because GCC supports emulated TLS.
- RISC-V is the only architecture in LLVM that does not support emulated
TLS, and work is being done to at least warn the users about it
(D143619).
With all these in mind I believe it is important to address the
consumers' needs especially given that there is little to no maintenance
downsides.
Differential Revision: https://reviews.llvm.org/D143708
We already had vector.transpose(vector.create_mask) ->
vector.create_mask. This patch adds the constant mask version of it.
Reviewed By: nicolasvasilache
Differential Revision: https://reviews.llvm.org/D147099
This is a variant of the existing `mapIterationSpaceDimToOperandDim`.
We have a local use downstream.
Reviewed By: nicolasvasilache
Differential Revision: https://reviews.llvm.org/D146857
linalg.fill was already vectorizable with masks but not supported in the
dynamic pre-checks.
Reviewed By: nicolasvasilache
Differential Revision: https://reviews.llvm.org/D146856
This patch removes the historical lhs and rhs masks in vector.contract,
now that vector.mask supports vector.contract and the lhs and rhs masks
are barely supported by all the vector.contract lowerings and
transformations.
Reviewed By: nicolasvasilache
Differential Revision: https://reviews.llvm.org/D144430
In `DebugValueManager`, if a `Def` is requested to be sunk to the same
place (i.e., `Insert` is right after `Def`, not counting `DBG_VALUE`s)
currently we still do the sink. This can result in unnecessary creation
of `DBG_VALUE $noreg`. See comments for details. This CL detects this
case and do nothing and return, so we don't end up creating unnecessary
undef `DBG_VALUE`s.
Reviewed By: dschuff
Differential Revision: https://reviews.llvm.org/D146860
The current `DebugValueManager`, which is mostly used in `RegStackify`,
simply sinks `DBG_VALUE`s along when a def instruction sinks.
(`RegStackify` only does sinks; it doesn't do hoists.)
But this simple strategy can result in incorrect combinations of
variables' values which would have not been possible in the original
program. In this case, LLVM's policy is to make the value unavailable,
so they will be shown as 'optimized out', rather than showing inaccurate
debug info. Especially, when an instruction sinks, its original
`DBG_VALUE` should be set to undef. This is well illustrated in the
third example in
https://llvm.org/docs/SourceLevelDebugging.html#instruction-scheduling.
This CL rewrites `DebugValueManager` with this principle in mind. When
sinking an instruction, it sinks its eligible `DBG_VALUE`s with it, but
also leaves undef `DBG_VALUE`s in the original place to make those
variables' values undefined.
Also, unlike the current version, we sink only an eligible subset of
`DBG_VALUE`s with a def instruction. See comments in the code for
details.
In case of cloning, because the original def is still there, we don't
set its `DBG_VALUE`s to undef. But we clone only an eligible subset of
`DBG_VALUE`s here as well.
One consequence of this change is that now we do sinking and cloning of
the def instruction itself within the `DebugValueManager`'s `sink` and
`clone` methods. This is necessary because the `DebugValueManager` needs
to know the original def's location before sinking and cloning in order
to scan other interfering `DBG_VALUE`s between the original def and the
insertion point. If we want to separate these two, we need to call
`DebugValueManager`'s `sink` and `clone` methods //before//
sinking/cloning the def instruction, which I don't think is a good
design alternative either, because the user of this class needs to pay
extra attention when using it.
Because this change is fixing the existing inaccuracy of the current
debug info, this reduces the variable info coverage in debug info, but
not by a large margin. In Emscripten core benchmarks compiled with
`-O1`, the coverage goes from 56.6% down to 55.2%, which I doubt will be
a noticeable drop. The compilation time doesn't have any meaningful
difference either with this change.
Reviewed By: dschuff
Differential Revision: https://reviews.llvm.org/D146744
The stdio test failures were due to headers potentially not being built
in the correct order. This should set up the dependencies correctly.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D146551
Currently calling stack locations is selected using `CALL` in ISel,
resulting in an invalid code and crashing in AsmPrinter. FastISel
correctly selects it will `CALL_INDIRECT`.
Fixes the problem reported in D146781.
Reviewed By: tlively, HerrCai0907
Differential Revision: https://reviews.llvm.org/D147033
An INLINEASM can have an implicit def of vcc. It is not appropriate for
fixImplicitOperands to change this to vcc_lo on wave32.
Differential Revision: https://reviews.llvm.org/D147157
Summary:
The AMDGPU ABI isn't stable or well defined. For that reson we prefer to
rely on LTO to ensure that multiple files get linked correctly.
Currently the internal targets used for testing mix LLVM-IR and
assembly. We should be consistent here.
Move out MemRefDependenceGraph analysis structure out of LoopFusion into
the Affine Analysis library. This had been a long pending TODO. Moving
MDG out allows its use in other affine passes as well as allows building
custom affine fusion passes downstream while reusing upstream fusion
utilties. The file LoopFusion.cpp had also become lengthy and this
change makes things more modular. This change is a pure NFC and is a
code movement.
NFC.
Reviewed By: springerm
Differential Revision: https://reviews.llvm.org/D147105
MSVC allows instantiations of exported or imported template classes with template
parameters that have internal linkage. Clang now allows it in Microsoft mode and for
the Playstation platform. This partially addresses issue 56068.
Note that MSVC also allows explicit dllexport/dllimport attributes on classes
with internal linkage (e.g. local classes or classes declared in anonymous name spaces).
Clang continues to reject such declarations.
Reviewed By: hans
Differential Revision: https://reviews.llvm.org/D146338
This patch fixes a crash that appear in an OpenMP MAX intrinsic
reduction when the reduction is not expressed using MAX intrinsic
function. Updated flang/test/Lower/OpenMP/wsloop-reduction-max.f90
test case with additional way of expressing MAX reduction.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D146967
The intent of this attribute is for it to be applied to a module and
then hold information on runtime library (RTL) flags given to
Flang (or other OpenMP frontend) that should be lowered down to
LLVM-IR for devices as LLVM globals. The following related
flags are:
-fopenmp-target-debug
-fopenmp-assume-threads-oversubscription
-fopenmp-assume-teams-oversubscription
-fopenmp-assume-no-nested-parallelism
-fopenmp-assume-no-thread-state
These exist within Clang and are lowered into the IR when
offloading for device. This attribute allows this infromation
to be carried down from the Flang frontend to the
LLVM/OpenMP Dialect to LLVM-IR translation phase
and then be lowered to LLVM-IR.
Reviewers: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D144896
This reverts commit 3b4cb1e96c645bb833fe710856479c31383859bb.
Reland D145718 but unconditionally define __sanitizer_mallinfo which is
exposed as part of the hwasan interface.
Differential Revision: https://reviews.llvm.org/D145718
mallinfo is platform-specific and not specified by either posix or the C
standard, but the hwasan interface unconditionally exposes
__sanitizer_mallinfo which returns a struct __sanitizer_struct_mallinfo
which is defined in sanitizer_platform_limits_posix.h, so this should
also be available for fuchsia to provide __sanitizer_mallinfo. Fuchsia
doesn't need the rest of what's in sanitizer_platform_limits_posix.h so
we can just move it to its own header.
Exposing this and not forcing it to hide behind
SANITIZER_INTERCEPT_MALLOPT_AND_MALLINFO fixes the test failures found
after landing D145718.
Differential Revision: https://reviews.llvm.org/D147092
Handle the splat and dense case.
I saw this pattern show up in a couple recent SPIR-V-specific bug
report.
Reviewed By: antiagainst
Differential Revision: https://reviews.llvm.org/D147109
circumstances when parsing ASTs
Fix ArgsAsWritten being null for ConceptSpecializationExpr in certain
circumstances when parsing ASTs
ASTStmtWriter::VisitConceptSpecializationExpr specifically expects
getTemplateArgsAsWritten() to return true, which it wasn't when parsed
by ASTContext.cpp in certain edge cases.
Fixes: #61486
Differential Revision: https://reviews.llvm.org/D146678
Error only applies if it is a whole array. Page 157 in OpenMP 5.2
standard.
Reviewed By: TIFitis
Differential Revision: https://reviews.llvm.org/D147142
When depend on template parameter,
compiler can use NullStmt instead of CompoundStmt.
This causes issues as we losing information about
end location of that Stmt. To avoid this issue
check now ignores ifStmt with NullStmt on true-branch.
Fixes: https://github.com/llvm/llvm-project/issues/61435
Reviewed By: carlosgalvezp
Differential Revision: https://reviews.llvm.org/D146887
This patches chagnes the type of map_operands to OpenMP_PointerLikeType for OMP Target Data directives.
Differential Revision: https://reviews.llvm.org/D147050
Commit 3d7946c58 implemented a DR that allowed us to error in a case
where an ill-formedness in a RequiresExpr is diagnosed as a satisfaction
failure. However, it failed to cover cases where the RequiresExpr had
Requirements that failed for similar reasons.
This patch propagates the RecoveryExpr "containsErrors" correctly
through RequiresExpr.
Fixes: #61776
This reverts commit ccdcfad0815296d8952438632d9abe6bc0a5258a.
Reason: Introduced an ODR that broke the ASan bots. See more information
in Phabricator: https://reviews.llvm.org/D146935
Ensure that the current symbol is added to the parent contexts in the
output of libclang function for generating symbol graphs for single symbols.
Differential Revision: https://reviews.llvm.org/D147138
Move the conversion of DILineInfo to JSON into a separate function, so
it can be used in other places too.
This is a prerequisite patch for implementation of symbol+offset lookup.
Differential Revision: https://reviews.llvm.org/D147112
llvm-symbolizer echoed input if it was not recognized as a valid address.
This behavior was extended to llvm-addr2line as well. GNU addr2line in
this case optputs "??:0". This difference prevents implementation of
symbol+offset lookup available in the recent versions of GNU binutils.
In that case a string that is not an address may be a symbol.
This change make reaction of llvm-addr2line on unrecognized input closer
to GNU addr2line.
On AIX, the build-id can be embedded in a binary using the -mxcoff-build-id
compiler option. When present, the build id is stored as an ascii string at the
beginning of the string table in the loader section of the XCOFF file.
Reviewed By: stephenpeckham, daltenty
Differential Revision: https://reviews.llvm.org/D146976
