In https://reviews.llvm.org/D118972 I increased this buffer to be
big enough to import 261,144 classes but this is a lot more than
we currently have, an allocating a too-large buffer can add memory
pressure even if it's only for a short time. Reduce the size of
this memory buffer to big enough to import 163,840 classes. I'll
probably move to a scheme where we read the objc classes in chunks,
with a smaller buffer and multiple inferior function calls.
rdar://91275493
The LLVM IR verifier and analysis linter defines and uses several macros in
code that performs validation of IR expectations. Previously, these macros
were named with an 'Assert' prefix. These names were misleading since the
macro definitions are not conditioned on build kind; they are defined
identically in builds that have asserts enabled and those that do not. This
was confusing since an LLVM developer might expect these macros to be
conditionally enabled as 'assert' is. Further confusion was possible since
the LLVM IR verifier is implicitly disabled (in Clang::ConstructJob()) for
builds without asserts enabled, but only for Clang driver invocations; not
for clang -cc1 invocations. This could make it appear that the macros were
not active for builds without asserts enabled, e.g. when investigating
behavior using the Clang driver, and thus lead to surprises when running
tests that exercise the clang -cc1 interface.
This change renames this set of macros as follows:
Assert -> Check
AssertDI -> CheckDI
AssertTBAA -> CheckTBAA
Partially inlining a libcall that has the musttail attribute
leads to broken LLVM IR, triggering an assertion in the IR verifier.
Reviewed By: lebedev.ri
Differential Revision: https://reviews.llvm.org/D123116
Currently, the LLVM/LLDB timers are visible in Instruments for all apps.
The developer-visible "PointsOfInterest" category is reserved for
runtime issues and developer-authored "important" logging. These logs
are visible to developer almost always in Instruments
The LLVM/LLDB timers do not belong there. Having these present in the
system is noisy and confusing to developers. This patch moves them under
a new "toolchain" category.
rdar://91266582
Differential revision: https://reviews.llvm.org/D123149
It turns out we don't do an awesome job with weird types like s318 (and other
types near them, like s316).
We don't have any test coverage for those types, so let's add some so it's
easier to see the impact of legalization improvements on them when we make
changes.
Since the test generator was changed, it's easier to update relevant tests prior
to changing things rather than squinting at a bunch of "ah, CHECK is now
CHECK-NEXT" lines. So, let's just regenerate a bunch of tests while we're
here.
Unfortunately the "CHECK-NEXT" scheme doesn't work with legalize-cmp for some
reason, and the test will fail. So keep that one having CHECK lines.
The diagnostic is unreliable, and triggers even for dead uses of
hostcall that may exist when linking the device-libs at lower
optimization levels.
Eliminate the diagnostic, and directly document the limitation for
OpenCL before code object V5.
Make some NFC changes to clarify the related code in the
MetadataStreamer.
Add a clang test to tie OCL sources containing printf to the backend IR
tests for this situation.
Reviewed By: sameerds, arsenm, yaxunl
Differential Revision: https://reviews.llvm.org/D121951
Right now `populateVectorInsertExtractStridedSliceTransforms` contains
two categories of patterns, one for decomposing high-D insert/extract
strided slices, the other for lowering them to shuffle ops.
They are at different levels---the former is in the middle, while
the latter is a step of final lowering. Split them to give users
more control of which pattern to pick.
This means break down the previous `VectorExtractStridedSliceOpRewritePattern`,
which is doing two things together.
Also renamed those patterns to be clearer.
Reviewed By: ThomasRaoux
Differential Revision: https://reviews.llvm.org/D123137
NFC
When no actual change happens there's no need to notify the
observers about the fact the register class is being constrained.
So we should avoid notifying observers when no change has
happened, because this can dramatically affect compile
time for particular test cases.
Reviewed By: dsanders, arsenm
Differential Revision: https://reviews.llvm.org/D122615
This patch implements stderr/stdout forwarding on windows.
This was previously not implemented in D99974.
I added separate callbacks so the output can be sent to the different channels VSCode provides (OutputType::Stdout, OutputType::Stderr, OutputType::Console).
This patch also passes a log callback handler to SBDebugger::Create to be able to see logging output when it is enabled.
Since the output is now redirect on early startup I removed the calls to SetOutputFileHandle/SetErrorFileHandle, which set them to /dev/null.
I send the output of stderr/stdout/lldb log to OutputType::Console
Reviewed By: wallace
Differential Revision: https://reviews.llvm.org/D123025
This class is intended to be used in cases where a class is being used
on a va_list. It provides destruction and copy semantics with small
overhead. This is intended to be used in printf.
Reviewed By: sivachandra, lntue
Differential Revision: https://reviews.llvm.org/D123061
D122746 missed the following tests, so this patch adds them.
This patch refactors D122949, which marked the following tests XFAIL, but it makes more sense to temporarily add `--format=gnu` option because these tests aren’t testing `llvm-ar` and AIX won’t lose their coverage.
Reviewed By: jhenderson, MaskRay, DiggerLin
Differential Revision: https://reviews.llvm.org/D123063
In order to use the MLIR LSP server in Emacs, first the `mlir-lsp-client.el`
has to be loaded via elisp and then, one should call `lsp-mlir-setup` function
to setup the LSP client. After that simply calling the `lsp` function while
the `mlir-mode` is active with result in finding the language server (default
to `mlir-lsp-server`) via the `lsp-mlir-server-executable` customization variable
and connecting to it by the LSP library. Users who use MLIR's language server
library to create their own server can simply set the variable `lsp-mlir-server-executable`
to point to their own implementation executable.
Reviewed By: tschuett
Differential Revision: https://reviews.llvm.org/D123002
Add support for computing the symbolic integer lexmin of a polyhedron.
This finds, for every assignment to the symbols, the lexicographically
minimum value attained by the dimensions. For example, the symbolic lexmin
of the set
`(x, y)[a, b, c] : (a <= x, b <= x, x <= c)`
can be written as
```
x = a if b <= a, a <= c
x = b if a < b, b <= c
```
This also finds the set of assignments to the symbols that make the lexmin unbounded.
This was previously landed in da92f92621 and
reverted in b238c252e8 due to a build failure
in the code. Re-landing now with a fixed build.
Reviewed By: Groverkss
Differential Revision: https://reviews.llvm.org/D122985
I miss more automatically refactoring functions when working with already running code, so I am making some small addition that I hope help more people.
This works by checking if the function is a method (CXXMethodDecl), then collecting information about the function that the code is being extracted, looking for the declaration if it is out-of-line, creating the declaration if it is necessary and putting the extracted function as a class-method.
This is my first code review request, sorry if I did something wrong.
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D122698
Since enumerators may not be available in every translation unit they
can't be reliably used to name entities. (this also makes simplified
template name roundtripping infeasible - since the expected name could
only be rebuilt if the enumeration definition could be found (or only if
it couldn't be found, depending on the context of the original name))
On Windows, like on macOS and FreeBSD, widening char(-5) in the
"C" locale succeeds and produces L'\u00fb'.
Switch widen_many to test \xfb instead of \x85; the mingw
version of btowc widens \x85 in the "C" locale into
\u2026 (which is the corresponding character according to the
Windows-1252 codepage), while Microsoft CRT's btowc widens it
into \u0085 (just like macOS and FreeBSD). Switch this to test \xfb
which is the character tested by the widen_1 test (as `char(-5)`),
which gets handled the same by all Windows implementations of btowc.
Differential Revision: https://reviews.llvm.org/D121003
The DXIL Prepare pass handles the IR mutations required to convert
modern LLVM IR into something that more closely resembles LLVM-3.7 IR
so that the DXIL bitcode writer can emit 3.7 IR.
This change adds the codegen pass handling the first two IR
transformations:
* stripping new function attributes
* converting fneg into fsub
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D122081
This removes tens of warnings from build logs that we can't do
anything about.
Reviewed By: pcf000
Differential Revision: https://reviews.llvm.org/D122927
We can do this conversion by converting the same sized integer type, then compare the result with 0. The conversion is undefined if the converted FP value doesn't fit in an i1.
Reviewed By: frasercrmck
Differential Revision: https://reviews.llvm.org/D122678
Improve the documentation for the platform functions that take a process
host architecture as input.
Differential revision: https://reviews.llvm.org/D122767
Fix undefined behavior in AppleObjCRuntimeV2 where we were left shifting
a signed value. This also removes redundant casts of unobfuscated to
uint64_t which it already is.
rdar://91242879
Differential revision: https://reviews.llvm.org/D123098
[libc++] add global variable template std::views::empty
Note it is neither a range adaptor, nor a CPO. It is simplify a global variable template.
Reviewed By: #libc, Mordante
Differential Revision: https://reviews.llvm.org/D122996
Originally in the returnOp conversion, the result type was changing to bare
pointer if the type was a memref. This is incorrect as conversion to bare
pointer can only be done if the memref has static shape, strides and offset.
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D123121
This iterator is used to test code that only needs to satisfy the
output_iterator concept. Follow-up changes will use this iterator in
older language Standards.
Reviewed By: ldionne, #libc, philnik, var-const
Differential Revision: https://reviews.llvm.org/D122072
Fix https://github.com/flang-compiler/f18-llvm-project/issues/1416.
The `constRows` variable was being decremented too soon, causing the
last constant interior dimension extent being used to multiply the GEP
offset. This lead to wrong address computation and caused segfaults.
Note: also upstream fir.embox tests that can be upstreamed.
Differential Revision: https://reviews.llvm.org/D123130
Do not use the shift of a fir.embox to set lower bounds if there is
a fir.slice operand. This matches Fortran semantics where lower bounds
of array sections are ones.
Note that in case there is a fir.slice, the array shift may be provided
because it is used to calculate the origin/base address of an array slice.
Add a TODO for substring codegen since I noticed it was not upstreamed
yet and would cause some program to silently compile incorrectly.
Differential Revision: https://reviews.llvm.org/D123123
Currently, clang-offload-bundler has -inputs and -outputs options that accept
values with comma as the delimiter. This causes issues with file paths
containing commas, which are valid file paths on Linux.
This add two new options -input and -output, which accept one single file,
and allow multiple instances. This allows arbitrary file paths. The old
-inputs and -outputs options will be kept for backward compatibility, but
are not allowed to be used with -input and -output options for simplicity.
In the future, -inputs and -outputs options will be phasing out.
RFC: https://discourse.llvm.org/t/rfc-adding-input-and-output-options-to-clang-offload-bundler/60049
Patch by: Siu Chi Chan
Reviewed by: Yaxun Liu
Differential Revision: https://reviews.llvm.org/D120662
Instead of using `.fail.cpp` tests, use `.verify.cpp` to check for the
exact reason of the failure. In the case of deduction guides, use SFINAE
based tests instead since that is our preferred way of testing those.
Finally, ensure that we actually run the test in `iter_alloc_deduction.pass.cpp`,
since we were not running anything before.
Differential Revision: https://reviews.llvm.org/D123055