| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This PR lets users provide --debug-only flags with python decorators.
This greatly simplifies the debugging experience in python.
Co-authored-by: Tres <tpopp@users.noreply.github.com>
|
|
management
Co-authored-by: Fabian Mora <fmora.dev@gmail.com
Co-authored-by: Oleksandr "Alex" Zinenko <git@ozinenko.com>
Co-authored-by: Tres <tpopp@users.noreply.github.com>
|
|
(#146892)
Use `make_early_inc_range` when erasing operations from a block to make
sure that the iterator is not invalidated. The previous implementation
happened to work on a "normal" dialect conversion because some IR
modifications are delayed. It no longer works with a One-Shot Dialect
Conversion. The new One-Shot Dialect Conversion API is more similar to
the normal rewriter API.
|
|
Previously the parameter wasn't respected. So we would only run the test
with whatever stdlib the `Makefile.rules` deduced.
Confirmed that
```
lldb-dotest -p TestDataFormatterGenericSet.py --category libstdcxx
```
passes on my machine.
|
|
We don't want this as part of the public API, and using LLDB_LOG avoids
some warnings when compiling on Windows.
|
|
Split out from #146740
|
|
Split out from https://github.com/llvm/llvm-project/pull/146740
|
|
I must have been mistaken because this test does still fail
on Windows on Arm. At least the test code is Windows compatible
now.
|
|
Remove unused code and unnecessary function calls, optimize global
variable search.
Add more test cases.
|
|
The 'cache' construct is lowered as marking the acc.loop in ACC MLIR.
This results in any variable references that are not inside of the
acc.loop being invalid. This patch adds a warning to that effect, and
ensures that the variable references won't be added to the AST during
parsing so we don't try to lower them.
This results in loss of instantiation-diagnostics for these, however
that seems like an acceptable consequence to ignoring it.
|
|
Reverts llvm/llvm-project#146297 because #131837 is reverted in #146850
|
|
PR145731 corrected the analyzer test runner to consider use of z3 when
used by testcases, which exposed problems in test cases PR37855.c and
crashes in z3-crosscheck.c This change fixes those crashes and
re-enables the test cases that were "XFAIL"'d out.
Co-authored-by: einvbri <vince.a.bridgers@ericsson.com>
|
|
This patch is part of a series that adds origin-tracking to the debugify
source location coverage checks, allowing us to report symbolized stack
traces of the point where missing source locations appear.
This patch adds the logic for collecting stack traces in DebugLoc
instances. We do not symbolize the stack traces in this patch - that
only happens when we decide to actually print them, which will be the
responsibility of debugify. The collection happens in the constructor of
a DebugLoc that has neither a valid location nor an annotation; we also
collect an extra stack trace every time we call setDebugLoc, as
sometimes the more interesting point is not where the DebugLoc was
constructed, but where it was applied to an instruction. This takes the
form of a getCopied() method on DebugLoc, which is the identity function
in normal builds, but adds an extra stack trace in origin-tracking
builds.
|
|
|
|
(#146347)
|
|
Without the ":" it doesn't work.
|
|
It must be "REQUIRES:", "REQUIRES :" does not actually check
the requirement.
|
|
The target is called "x86" not "x86_64".
|
|
Two problems here:
* Missing ":" after REQUIRES, so it was never checked for
and ran anyway.
* The target name is "x86" not "x86_64".
|
|
Nested AddRec is already rejected by the handling in pushSCEV().
|
|
Add abbreviations for icmp/fcmp, store and br, which are the most common
instructions that don't have abbreviations yet. This requires increasing
the abbreviation size to 5 bits.
This gives about 3-5% bitcode size reductions for the clang build.
|
|
|
|
When there is a function that is inlined at the current program counter.
If you get the current `line_entry` using the program counter's address
it will point to the location of the inline function that may be in
another file. (this is in implicit step-in and should not happen what
step over is called).
Use the current frame to get the `line_entry`
|
|
PPC does not use comdat. There is no need to check for that in the test,
just remove it.
Fix for https://lab.llvm.org/buildbot/#/builders/201/builds/5278
|
|
The current DITypeAttr caching for derived type debug metadata
generation strategy is not optimal. This turns out to be an issue for
compile times in apps with very very complex derived types like CP2K
See the added debug-cyclic-derived-type-caching-simple.f90 test for more
details about the duplication issue.
As a real world example justifying the new non trivial caching strategy,
in CP2K, emitting debug type info for the swarm_worker_type` in swarm_worker.F
caused 1,747,347 llvm debug metadata nodes to be emitted instead of 8023
after this patch (200x less) leading to noticeable compile time
improvements (I measured 0.12s spent in `AddDebugInfo` pass instead of
7.5s prior to this patch).
The main idea is that caching is now associating to the cached
DITypeAttr tree for a derived type a list of parent nodes being referred
to recursively via indices in this DITypeAttr.
When leaving the context of a parent node, all types that were cached
and linked to this parent node are cleared from the cache.
This allows more reusage in sub-trees while still fulfilling the MLIR
requirements that DITypeAttr types referring to a parent DITypeAttr via
integer id should only be used inside the DITypeAttr of the parent.
Most of the complexity comes from computing the "list of parent nodes"
by merging the ones from the components.
This is made is such a way that the extra cost for apps without
recursive derived type is minimal because the extra data structure
should not require extra dynamic allocations when they are no or little
recursion.
Example:
Take the following type graph (Fortran source for it in the added
debug-cyclic-derived-type-caching-complex.f90).
A is the tope level types, and has direct components of types B, C, and
E.
There are cycles in the type tree introduced by type B and D.
Types `C` and `E` are of interest here because they are in the middle of
those cycles and appear in several places in the type tree. There
occurrences is labeled in brackets in the order of visit by the
DebugTypeGenerator.
```
A -> B -> C [1] -> D -> E [1] -> F -> G -> B
| | | |
| | | | -> D
| | |
| | | -> H -> E [2] -> F -> G -> B
| | |
| | |-> D
| |
| | -> I -> E [3] -> F -> G -> B
| | |
| | |-> D
| | -> C [2]
|
| -> C [3] -> D
| -> E [4] -> F -> G -> B
|
| -> D
```
With this patch, E[2] and E[3] can share the same DITypeAttr as well as
C[1] and C[2] while they previously all got there own nodes.
To be safe with regards to cycles in MLIR, a DITypeAttr created for a
node N2 under a node N1 being recursively referred to and above the
recursive reference to N1 shall not be used above N1 in the DITypeAttr
tree. It can however be used in several places under N1.
Hence here:
-E[2] cannot reuse E[1] DITypeAttr because D appears above and under
E[1].
-E[3] can reuse E[2] DITypeAttr because they are both under B and above
D.
-E[4] cannot reuse E[3] DITypeAttr because it is above B.
This is achieved by this patch because when visiting A and reaching B,
the recursive reference to B is registered in the visit context. This
context is added D when going back-up in F. So when reaching back E[1]
with the information to build its DITypeAttr, its recursive references
are known and saved along the DITypeAttr in the cache.
When reaching back D, the cache for E is cleared because it is known it
depended on D. A new DITypeAttr is created after E[2], and this time it
only depends on B because the D under E[2] is not a recursive reference
(D is not above E[2]). Hence, when reaching E[3] it can be reused, and
the cache entry for E[2] is cleared when reaching B, which leads to a
new DITypeAttr to be created for E[4].
|
|
|
|
This is a generalization of the existing cloneToNewContext operation:
rather than cloning the given module into a new ThreadSafeContext it
clones it into any given ThreadSafeContext. The given ThreadSafeContext
is locked to ensure that the cloning operation is safe.
|
|
As discussed in PR #142353, the current testsuite of the `clang` Python
bindings has several issues:
- It `libclang.so` cannot be loaded into `python` to run the testsuite,
the whole `ninja check-all` aborts.
- The result of running the testsuite isn't report like the `lit`-based
tests, rendering them almost invisible.
- The testsuite is disabled in a non-obvious way (`RUN_PYTHON_TESTS`) in
`tests/CMakeLists.txt`, which again doesn't show up in the test results.
All these issues can be avoided by integrating the Python bindings tests
with `lit`, which is what this patch does:
- The actual test lives in `clang/test/bindings/python/bindings.sh` and
is run by `lit`.
- The current `clang/bindings/python/tests` directory (minus the
now-subperfluous `CMakeLists.txt`) is moved into the same directory.
- The check if `libclang` is loadable (originally from PR #142353) is
now handled via a new `lit` feature, `libclang-loadable`.
- The various ways to disable the tests have been turned into `XFAIL`s
as appropriate. This isn't complete and not completely tested yet.
Tested on `sparc-sun-solaris2.11`, `sparcv9-sun-solaris2.11`,
`i386-pc-solaris2.11`, `amd64-pc-solaris2.11`, `i686-pc-linux-gnu`, and
`x86_64-pc-linux-gnu`.
Co-authored-by: Rainer Orth <ro@gcc.gnu.org>
|
|
Reverting because mis-compiles:
- https://github.com/llvm/llvm-project/pull/131837
- https://github.com/llvm/llvm-project/pull/146320
- https://github.com/llvm/llvm-project/pull/146337
|
|
Accessing an erased operation will no longer work during a One-Shot
Dialect Conversion.
|
|
and XAndesVPackFPH. NFC.
|
|
Outdated pointee-type phrasings in ABI attributes have been removed.
|
|
See the attached test for the motiviation.
Previously we dependent on the module ownership of the decl context to
perform module local lookup. But if the lookup is unqualified, we may
perform the lookup with canonical decl, which belongs to the incorrect
named module
|
|
Proposal
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1979r0.html
appears to already be implemented as of Clang17. See:
https://godbolt.org/z/h59Mvzq6P
|
|
(#146695)
createEVLRecipe tries to optimise recipes that use the header mask by
replacing them with their VP equivalents and setting the EVL, allowing
the mask to be removed.
However we currently also convert widened selects to vp.select even
though they don't necessarily use the header mask.
Unlike vp.merge a vp.select only makes the "unused" lanes past EVL
poison, so it's not needed for correctness.
In the same vein as #127180, this patch removes the transform for
VPWidenSelectRecipes and keeps them as plain select instructions to
allow for more optimisations.
RISCVVLOptimizer will still be able to optimise away any VL toggles and
we end up with better code generation across llvm-test-suite and SPEC
CPU 2017.
|
|
As seen on Linaro's Windows on Arm bot.
C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\source\Host\windows\MainLoopWindows.cpp(80,25): warning: missing field 'InternalHigh' initializer [-Wmissing-field-initializers]
80 | OVERLAPPED ov = {0};
| ^
C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\source\Host\windows\MainLoopWindows.cpp(135,8): warning: 'WillPoll' overrides a member function but is not marked 'override' [-Winconsistent-missing-override]
135 | void WillPoll() {
| ^
C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\include\lldb/Host/windows/MainLoopWindows.h(40,18): note: overridden virtual function is here
40 | virtual void WillPoll() {}
| ^
C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\source\Host\windows\MainLoopWindows.cpp(142,8): warning: 'DidPoll' overrides a member function but is not marked 'override' [-Winconsistent-missing-override]
142 | void DidPoll() {
| ^
C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\include\lldb/Host/windows/MainLoopWindows.h(41,18): note: overridden virtual function is here
41 | virtual void DidPoll() {}
| ^
C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\source\Host\windows\MainLoopWindows.cpp(80,25): warning: missing field 'InternalHigh' initializer [-Wmissing-field-initializers]
80 | OVERLAPPED ov = {0};
| ^
|
|
Not that we ever do that, because this is unused code, but if someone
was debugging lldb I guess they'd call this.
Was missed in https://github.com/llvm/llvm-project/pull/145645
Relates to https://github.com/llvm/llvm-project/issues/135208
|
|
Fix the following compile error when building libMLIRDialectUtils.a
only:
In file included from
mlir/include/mlir/Dialect/Utils/ReshapeOpsUtils.h:17,
from mlir/lib/Dialect/Utils/ReshapeOpsUtils.cpp:9:
mlir/include/mlir/Dialect/Arith/IR/Arith.h:28:10:
fatal error: mlir/Dialect/Arith/IR/ArithOpsDialect.h.inc: No such file
or directory
ArithDialect dependency is now needed since
0515449f6dcb452ea0b089fb3057d469c3cffa3f to create arith.muli op.
|
|
Fails there https://lab.llvm.org/buildbot/#/builders/211/builds/197.
|
|
It looks like #146603 broke the
[lldb-remote-linux-win](https://lab.llvm.org/buildbot/#/builders/197)
build bot because `MCPUnixSocketCommandTestCase` is trying to start a
protocol-server via unix domain sockets on windows.
This change makes it so the test is skipped if it is remote.
|
|
|
|
Previously we only folded TargetGlobalAddresses into the memarg if they
were on their own, so this patch supports folding TargetGlobalAddresses
that are added to some other offset.
Previously we weren't able to do this because we didn't have nuw on the
add, but we can now that getelementptr has nuw and is plumbed through to
the add in 0564d0665b302d1c7861e03d2995612f46613a0f.
Fixes #61930
|
|
Relates to https://github.com/llvm/llvm-project/issues/22139
Just had to use the right win32 call instead of getpid. The original
problem was something with expressions in general which was
fixed at some point.
Also make the test one method, there's no need to split it up.
|
|
|
|
In 563bea91222f534d90c2baa645a5e2bc4132e9a8 I misssed calling
getpid. Which still works but doesn't do what we intended.
|
|
Relates to https://github.com/llvm/llvm-project/issues/22139
This used to be broken because the expressions didn't work,
but the test also used getpid which isn't avaialable on Windows.
So when the expressions started working, evaluation still failed
due to getpid.
I made it call GetCurrentProcessId and it worked.
|
|
This is combination of https://github.com/llvm/llvm-project/pull/138149
and https://github.com/llvm/llvm-project/pull/138039 which were opened
separately for ease of reviewing. Only other change is adjustments in 2
tests which have gone in since.
There are `DeclareOp` present for the variables mapped into target
region. That allow us to generate debug information for them. But the
`TargetOp` is still part of parent function and those variables get the
parent function's `DISubprogram` as a scope.
In `OMPIRBuilder`, a new function is created for the `TargetOp`. We also
create a new `DISubprogram` for it. All the variables that were in the
target region now have to be updated to have the correct scope. This
after the fact updating of
debug information becomes very difficult in certain cases. Take the
example of variable arrays. The type of those arrays depend on the
artificial `DILocalVariable`(s) which hold the size(s) of the array.
This new function will now require that we generate the new variable and
and new types. Similar issue exist for character type variables too.
To avoid this after the fact updating, this PR generates a
`DISubprogramAttr` for the `TargetOp` while generating the debug info in
`flang`. Then we don't need to generate a `DISubprogram` in
`OMPIRBuilder`. This change is made a bit more complicated by the the
fact that in new scheme, the debug location already points to the new
`DISubprogram` by the time it reaches `convertOmpTarget`. But we need
some code generation in the parent function so we have to carefully
manage the debug locations.
This fixes issue `#134991`.
|
|
The `current_module` pointer here was never set, but we check it when
looping over the `target_modules` list. Presumably the intention was to
avoid calling `LookupInModule` if we already found the type in the
current module. This patch removes this `current_module`. If we decide
the output below is not what the user should see, we can revisit the
implementation.
Current output:
```
(lldb) im loo -vt Foo --all
Best match found in /Users/jonas/Git/llvm-worktrees/llvm-project/a.out:
id = {0x00000037}, name = "Foo", byte-size = 1, decl = foo.cpp:1, compiler_type = "struct Foo {
}"
1 match found in /Users/jonas/Git/llvm-worktrees/llvm-project/a.out:
id = {0x00000037}, name = "Foo", byte-size = 1, decl = foo.cpp:1, compiler_type = "struct Foo {
}"
```
which seems fine.
Note, there can be multiple matches *within* the current module, so if
we did the naive thing of skipping the `current_module` when printing
with `--all`, then we would miss some matches.
|
|
Follow-up to
https://github.com/llvm/llvm-project/pull/145645#discussion_r2174948997
There's no need for this variable to be declared at the function-level.
We reset it in all the cases where it's used anyway.
This patch just inlines the usage of the variable entirely.
|
|
#146562 made
[TestCallStdStringFunction](https://github.com/llvm/llvm-project/blob/bd6cd92984e7a30cb91e4f069a0bacc5c582a234/lldb/test/API/commands/expression/call-function/TestCallStdStringFunction.py)
unexpectedly pass on Windows.
The test now passes, because `expression str` now prints the "raw"
string object, which happens to include the string "Hello world".
Previously, this resulted in an error:
```
(lldb) expression str
(std::string) $0 = {
_Mypair = {
_Myval2 = {
_Bx = (_Buf = "Hello world", _Ptr = "", _Alias = "Hello world")
_Mysize = 11
_Myres = 15
}
}
}
(lldb) type summary add std::string --summary-string "${var._M_dataplus._M_p}"
^^^ previous summary ^^^
(lldb) expression str
(std::string) $1 = error: summary string parsing error
```
#143177 will eventually add the correct summary for MSVC STL strings.
Relates to https://github.com/llvm/llvm-project/issues/22139
|
