Rename parameter in Sema::addInitCapture as proposed in review of Sema::addInitCapture. Sorry, that I have missed the comment there!
Reviewed By: ilya-biryukov
Differential Revision: https://reviews.llvm.org/D139541
CMake older than 3.20.0 is no longer supported.
This removes work-arounds for no longer supported versions.
Reviewed By: kwk
Differential Revision: https://reviews.llvm.org/D152103
Clang currently supports disabling color diagnostic output via
-fno-color-diagnostics. However, there is a somewhat long-standing push
to support use of an environment variable to override color output so
that users can set up their terminal such that most color output is
disabled (largely for accessibility reasons).
There are two competing de facto standards to accomplish this:
NO_COLOR (https://no-color.org/) and
CLICOLOR/CLICOLOR_FORCE (http://bixense.com/clicolors/).
This patch adds support for NO_COLOR as that appears to be the more
commonly supported feature, at least when comparing issues and pull
requests:
https://github.com/search?q=NO_COLOR&type=issues (2.2k issues, 35k pull requests)
https://github.com/search?q=CLICOLOR&type=issues (1k issues, 3k pull requests)
It's also the more straightforward and thoroughly-specified of the two
options. If NO_COLOR is present as an environment variable (regardless
of value), color output is suppressed unless the command line specifies
use of color output (command line takes precedence over the environment
variable).
Differential Revision: https://reviews.llvm.org/D152285
CMake older than 3.20.0 is no longer supported.
This removes work-arounds for no longer supported versions.
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D152101
CMake older than 3.20.0 is no longer supported.
This removes work-arounds for no longer supported versions.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D152102
A function is already emitted in *GenInstrInfo.inc that takes Opcode
number and a set of supported Features and reports fatal error if some
of the required features are missing.
The information about features required by the particular opcode can be
reused by llvm-exegesis, so move its computation info a separate
computeRequiredFeatures() function. Then verifyInstructionPredicates()
can just compare the sets of available and required features computed by
the other functions.
This commit moves the definition of FeatureBitsets[] as well as CEFBS_*
enumerator values (that are indices into FeatureBitsets[] array) inside
the computeRequiredFeatures() function because these are implementation
details of that function. The inclusion of potentially huge
computeRequiredFeatures() function is now controlled by a dedicated
macro that is set for simplicity by TableGen-erated code itself if
`defined(ENABLE_INSTR_PREDICATE_VERIFIER) && !defined(NDEBUG)`.
~~
Huawei RRI, OS Lab
Reviewed By: courbet
Differential Revision: https://reviews.llvm.org/D148516
Many command line option implementations, including getopt_long and our
Support/CommandLine.cpp, support `--` as an end-of-option indicator. All
the subsequent arguments are then treated as positional arguments.
D1387 added KIND_REMAINING_ARGS and 76ff1d915c9c42823a3f2b08ff936cf7a48933c5 dropped special handling of `--`.
Users need to add `def DASH_DASH : Option<["--"], "", KIND_REMAINING_ARGS>;` and
append `OPT_DASH_DASH` to the `OPT_INPUT` list., which is not ergonomic.
Restore this feature under an option and modify llvm-strings to utilize the
feature as an example. In the future, we probably should enable this feature by
default and exclude some tools that handle `DASH_DASH` differently (clang,
clang-scan-deps, etc. I suspect that many are workarounds for LLVMOption not
supporting `--` as a built-in feature).
Reviewed By: serge-sans-paille
Differential Revision: https://reviews.llvm.org/D152286
LIBCXX_ENABLE_FILESYSTEM should represent whether the platform has
support for a filesystem, not just whether we support <filesystem>.
This patch slightly generalizes the setting to also encompass whether
we provide <fstream>, since that only makes sense when a filesystem is
supported.
Differential Revision: https://reviews.llvm.org/D152168
Typically the size required to represent a dirent is stored in `d_reclen`. But
this not always the case for FreeBSD (for example, when walking a directory
over NFS).
This leads to ASAN false positives for `scandir` and similar functions. Because
ASAN uses `d_reclen` for the range to validate, it can overrun when `d_reclen` is
incorrect (too large).
This change adds `__sanitizer_dirsiz` which fixes the dirent size calculation
for FreeBSD. Other platforms continue to use `d_reclen`.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D151583
DeclPrinter::VisitCXXRecordDecl did not output qualifiers for records.
As result, the output of out-of-line record definitions was incorrect.
Differential Revision: https://reviews.llvm.org/D151528
We need to allow recursive application of intrinsic lowering patterns,
otherwise we cannot lower nested calls of the same intrinsic e.g.
matmul(matmul(a, b), c).
matmul(matmul(a, b), matmul(c, d)) requires hlfir.associate of hlfir
expr with more than one use (TODO).
Differential Revision: https://reviews.llvm.org/D152284
The verifiers for hlfir.matmul and hlfir.transpose try to ensure that
the shape of the result value makes sense given the shapes of the input
argument(s).
It there are some cases in the gfortran tests where lowering knows a bit
more about shape information than (HL)FIR. I think the cases here will be
solved when hlfir.shape_meet is implemented.
But in the meantime, and to improve robustness, I've relaxed the
verifier to allow the return type to have more precise shape information
than can be deduced from the argument type(s).
Differential Revision: https://reviews.llvm.org/D152254
For Neon, the default nonconst stride cost is conservative,
and it is a local variable, which is not convenience to
to tune the loop vectorize.
So I try to use a option, which is similar to SVEGatherOverhead brought in D115143.
Fix https://github.com/llvm/llvm-project/issues/63082.
Reviewed By: dmgreen, fhahn
Differential Revision: https://reviews.llvm.org/D152253
Reasons for rolling forward:
- the crash reported from Chromium was fixed in D151824 (not related to this patch at all)
- since D152824 was committed, it should now be safe to roll this forward.
New change:
- add an additional _ in name check
This reverts commit 4980eead4d0b4666d53dad07afb091375b3a13a0.
Device libs make use of patterns like this:
```
__attribute__((target("gfx11-insts")))
static unsigned do_intrin_stuff(void)
{
return __builtin_amdgcn_s_sendmsg_rtnl(0x0);
}
```
For functions that are assumed to be eliminated if the currennt GPU target doesn't support them.
At O0 such functions aren't eliminated by common optimizations but often by AMDGPURemoveIncompatibleFunctions instead, which sees the "+gfx11-insts" attribute on, say, GFX9 and knows it's not valid, so it removes the function.
D142907 accidentally made it so such attributes were dropped during bitcode linking, making it impossible for RemoveIncompatibleFunctions to catch the functions and causing ISel to catch fire eventually.
This fixes the issue and adds a new test to ensure we don't accidentally fall into this trap again.
Fixes SWDEV-403642
Reviewed By: arsenm, yaxunl
Differential Revision: https://reviews.llvm.org/D152251
- This patch proposes to add `!setdagarg` and `!setdagname` bang
operators to produce a new DAG node after replacing the specified
argument value/name from the given input DAG node. E.g.,
`!setdagarg((foo 1, 2), 0, "x")` produces `(foo "x", 2)` and
`!setdagname((foo 1:$a, 2:$b), 1, "c")` produces `(foo 1:$a, 2:$c)`.
Reviewed By: simon_tatham
Differential Revision: https://reviews.llvm.org/D151842
This adds a commutative version of VSelectPredOrPassthruPatFrags (renamed from
EitherVSelectOrPassthruPatFrags) that checks both variants for commutative
operations like min/max. I have not attempted to handle fp operation that
require fast-math flags.
Differential Revision: https://reviews.llvm.org/D151084
This change tries to move registerTargetglobalVariable and
getAddrOfDeclareTargetVar out of Clang's CGOpenMPRuntime
and into the OMPIRBuilder for shared use with MLIR's OpenMPDialect
and Flang (or other languages that may want to utilise it).
This primarily does this by trying to hoist the Clang specific
types into arguments or callback functions in the form of
lambdas, replacing it with LLVM equivelants and
utilising shared OMPIRBuilder enumerators for
the clauses, rather than Clang's own variation.
Reviewers: jsjodin, jdoerfert
Differential Revision: https://reviews.llvm.org/D149162
This fixes broken mingw builds since
0a71e25e2448ee471b1ebe74e910c5de9b9c82b4. Clang-cl style builds
were broken similarly, but were fixed in
caa2c1bacbd76c017ebbb4fd13861f0f66770299, with the comment
"Do not redefine builtins on Windows", even if the fix only affected
Clang-cl style builds.
Adds a new HLFIR operation for the DOT_PRODUCT intrinsic according to
the design set out in flang/docs/HighLevel.md. This patch includes all
the necessary changes to create a new HLFIR operation and lower it into
the fir runtime call.
Differential Revision: https://reviews.llvm.org/D152252
The `exit` entrypoint calls into `quick_exit` which is marked noreturn
in some cases. This will cause errors because we then have control flow
externally. This warning can be silenced by using a
`__builtin_unreachable` instruction accordingly.
Reviewed By: sivachandra, lntue
Differential Revision: https://reviews.llvm.org/D152323
This patch implemed the change proposed in [P2002R1] to 11.11.1 [class.compare.default] paragraph 1.
A defaulted compariosn operator function must be non-volatile and must either have no ref-qualifier or the ref-qualifier &.
Differential Revision: https://reviews.llvm.org/D148924
There is a failure with this pass in the case when target register class for a subregister isn't known from instruction description (for ex. COPY).
Currently in this situation the RC is obtained using TargetRegisterInfo::getSubRegisterClass but in general it's not working.
In order to fix this two things should be done:
1. Stop processing a subregister if the target register class is unknown (conservative approach)
2. Improve deduction of subregister' target register class (i.e by processing COPY chain)
I was going to implement point 1 but my tests use implicit operands for S_NOP and they don't have associated target register class and all tests fail.
Therefore I decided to turn off the pass now, implement point 1 and fix my tests.
Reviewed By: arsenm, #amdgpu
Differential Revision: https://reviews.llvm.org/D152291
Consider only targets where `MCAsmInfo::ExceptionsType == ExceptionHandling::None`
and that support CFI (when `MCAsmInfo::UsesCFIForDebug` is set to true):
currently, only AMDGPU.
This patch enables the emission of CFI information in the .eh_frame
section when the uwtable attribute is present on a function.
Before, we could generate CFI information for debugging puproses only.
This patch prepares AMDGPU to support collecting GPU stack traces in the future.
I did a first implementation (https://reviews.llvm.org/D139024)
but at the time I had not realized that no other platform used
`UsesCFIForDebug`.
Reviewed By: scott.linder
Differential Revision: https://reviews.llvm.org/D151806
This patch splits the GlobalISelEmitter.cpp file, which imports DAG ISel patterns for GISel, into separate "GISelMatchTable.h/cpp" files.
The main motive is readability & maintainability. GlobalISelEmitter.cpp was about 6400 lines of mixed code, some bits implementing the match table codegen, some others dedicated to importing DAG patterns.
Now it's down to 2700 + a 2150 header + 2000 impl.
It's a tiny bit more lines overall but that's to be expected - moving
inline definitions to out-of-line, adding comments in the .cpp, etc. all of that takes additional space, but I think the tradeoff is worth it.
I did as little unrelated code changes as possible, I would say the biggest change is the introduction of the `gi` namespace used to prevent name conflicts/ODR violations with type common names such as `Matcher`.
It was previously not an issue because all of the code was in an anonymous namespace.
This moves all of the "match table" code out of the file, so predicates,
rules, and actions are all separated now. I believe this helps separating concerns, now `GlobalISelEmitter.cpp` is more focused on importing DAG patterns into GI, instead of also containing the whole match table internals as well.
Note: the new files have a "GISel" prefix to make them distinct from the other "GI" files in the same folder, which are for the combiner.
Reviewed By: aemerson
Differential Revision: https://reviews.llvm.org/D151432
