Reverts llvm/llvm-project#137408
This change broke `lldb/test/Shell/Unwind/split-machine-functions.test`.
The test binary has a symbol named `_Z3foov.cold` and the test expects
the backtrace to print the name of the cold part of the function like
this:
```
# SPLIT: frame #1: {{.*}}`foo() (.cold) +
```
but now it gets
```
frame #1: 0x000055555555514f split-machine-functions.test.tmp`foo() + 12
```
This PR is in reference to porting LLDB on AIX.
Link to discussions on llvm discourse and github:
1. https://discourse.llvm.org/t/port-lldb-to-ibm-aix/80640
2. https://github.com/llvm/llvm-project/issues/101657
The complete changes for porting are present in this draft PR:
https://github.com/llvm/llvm-project/pull/102601
- Added changes to make the common host support functions under
`Host/posix` for unix-like system.
Also, created the `unittests/Host/posix/` to test the hostInfo & support
functions for unix-like system.
- Added changes to get the host information for AIX. (GetProcessInfo())
(Information like : executable path, arch, process status etc.)
This adds a new filtering option to be used along with the
-header-include-format=json option. The existing "only-direct-system"
filtering option is missing some things:
- It does not show module imports.
- It does not show includes of non-system headers. This new
"direct-per-file" filtering has a separate entry in the JSON output for
each non-system source file, showing the direct includes and imports
from that file. You can use this to see uses of non-system headers, and
also find the paths through non-system headers that lead up to module
imports and system headers. Modules are identified here by their
modulemap files.
Fixes#132692.
`clang -cc1` crashes when generating a module interface with
`emit-module-interface` or `emit-reduced-module-interface` using an
input file which is already a precompiled module (`.pcm`) file.
This commit adds validation for the input file format and Clang will now
emit an error message instead of crashing.
The expensive checks bots found issues with #132481, due to not setting
defs/uses correctly. In 31bd7a5071 I added verify flags, so that the
failure is reproduced without requiring expensive checks, and xfailed
the test.
This change:
- Ensures that registers are correctly marked as defs/uses.
- Removes the xfail.
- Leaves the tests with `-verify-machineinstrs` which should have been
present originally.
This patch add the test for the fmuladd reduction to show the test
change/fail for the cost model change.
Note that without the fp128 load and trunc, there is no failure.
Pre-commit test for #113903.
On 64-bit platforms, libgcc doesn't ship with __clzsi2, so __builtin_clz
gets lowered to __clzdi2. A check already exists for GCC, but as of
commit 8210ca0198 clang also lowers
__builtin_clz to __clzdi2 on sparc64.
Update the check so that building __clzdi2 with clang/sparc64 also
works.
A GCC 7 requirement on the completeness of types before using them in a
variant means we need a constructor for these (or define them outside the
current thing). This patch should fix the build, as reported by
@kewen12
My previous commit was a bit sloppy, I didn't spot that
`lldb-dap.executable-path` already had a scope and I didn't consider
that `lldb-dap.log-path` should have the same scope.
This PR addresses both:
- Fix duplicate scope for `lldb-dap.executable-path`.
- Change scope of `lldb-dap.log-path` to `machine-overridable` too.
Mutating a node after it has been created isn't a good idea. After
e17f07c4de, we have a version of setStore
that can create a truncating indexed store. Use that instead of
MorphNodeTo+setTruncatingStore in PowerPC.
Unfortunately, if we return the newly created node, DAGCombiner will
visit the node and change the constant. To prevent this, we use
DCI.CombineTo and avoid adding the new node to the worklist.
In 42622c7959, depending on the entire
utility library resulted in the lldb binary having more symbols that it
needs, duplicating those in liblldb, leading to odr violations. Now
instead we just expose the Host library's headers, which happens to be
enough for this to compile and link, referencing the symbols from
liblldb
# Summary
This patch makes the `request_attach` wait for events `process` and
`initialized` just like `request_launch`. This ensure the DAP session
can move forward somewhat correctly.
Recently `TestDap_attach.test_terminate_commands` became flaky.
It's hitting:
```
lldbsuite/test/tools/lldb-dap/dap_server.py", line 350, in send_recv
raise ValueError(desc)
ValueError: no response for "disconnect"
```
I took a look at the DAP msg from that test case and noticed:
- It's not using the regular attaching, instead it's using the
`attachCommands` to launch debug the binary and it will stop at entry.
- The `initialized` event returned after the `disconnect` request. Which
means lldb-dap didn't really get ready yet.
### NOTE
The `dap_server.py` is doing things to mimic the VSCode (or other dap
clients) but it had some assumptions. For example, it's still missing
the `configurationDone` request and response because it relies on a
continue action to trigger the `configurationDone` request.
# Test Plan
```
./bin/llvm-lit -va /Users/wanyi/llvm-upstream/llvm-project/lldb/test/API/tools/lldb-dap/attach/TestDAP_attach.py
./bin/llvm-lit -va /Users/wanyi/llvm-upstream/llvm-project/lldb/test/API/tools/lldb-dap/launch/TestDAP_launch.py
```
To test the `wait_for_events` timeout case
```
events = self.wait_for_events(["process", "initialized", "fake", "event"], 1)
if events:
raise ValueError(f'no events {",".join(events)} found for within timeout 1')
```
Observed
<img width="696" alt="image"
src="https://github.com/user-attachments/assets/bc97c0ef-d91f-4561-8272-4d36f5f5d4e6"
/>
### Also
Looks like some test cases should be re-enabled in
0b8dfb5762
But only comments was removed. The skip statements survived the change.
Without this change files in `--start-lib`/`--end-lib` groups were being
marked as live, which means there static constructors were being
included in the link.
Like the NamespaceDecl, this is just emitted as a decl-context, where
all its internal declarations get emitted for it. The incubator doesn't
seem to have any good tests for this, so I wrote what I could think of
as a half-decent test for this one, though the lowering doesn't manage
whether these should be mangled, so the test is mostly just for
spot-checking purposes.
I'm implementing this as it will make writing further tests for future
features a little easier.
The 'loop' construct has some pretty strict checks as to what the for
loop associated with it has to look like. The previous implementation
was a little convoluted and missed implementing the 'condition'
checking. Additionally, it did a bad job double-diagnosing with
templates.
This patch rewrites it in a way that does a much better job with the
double-diagnosing, and proeprly implements some checks for the
'condition' of the for loop.
10s looks not enough. With highly parallel test
execution on VMs it's very possible that Asan
report will have no enough time to produce output.
I can reproduce locally 1s is not always enough,
but likely my workstation is faster then buildbot.
Additionally, don't use puts/CHECK to validate
timeout. We can exit with 0 and it should violate
"not" expectation.
Follow up to #131756.
This shows up in the extension UI and in the VSCode extension
marketplace.
I used the llvm/llvm-www/blob/main/img/LLVMWyvernSmall.png for the
image.
Here is what this looks like locally:
<img width="1020" alt="Screenshot 2025-04-28 at 12 30 33 PM"
src="https://github.com/user-attachments/assets/cd615161-06db-4a37-8f8a-df65ca620a67"
/>
Move out the logic to prepare for vectorization to a separate transform,
before creating loop regions. This was discussed as follow-up
in https://github.com/llvm/llvm-project/pull/136455.
This just moves the existing code around slightly and will simplify
follow-up patches to include the exiting edges during initial VPlan
construction.
The OpenMP implementation of the ATOMIC construct will change in the
near future to accommodate atomic conditional-update and conditional-
update-capture operations. This patch separates the shared implemen-
tations to avoid interfering with OpenACC.
The part that verifies the declare attributes are preserved in the
verifier can fail easily during the FIR lowering pipeline. For example,
during FIR lowering to FIRCG, fir.declare can be removed. Thus, any
fir.declare that has acc.declare attributes will cause a verifier
failure. Since the declare attribute only existed to simplify the effort
of locating acc declare enter and exit points, which can be easily
replaced by a def-use chain traversal, we are considering removing the
verification of declare attributes in this MR.
Example:
```
%1 = fir.alloca !fir.array<10xf32> {bindc_name = "arr", uniq_name = "_QMmmFsubEarr"}
%2 = fir.shape %c10 : (index) -> !fir.shape<1>
%3 = fir.declare %1(%2) {acc.declare = #acc.declare<dataClause = acc_create>, uniq_name = "_QMmmFsubEarr"} : (!fir.ref<!fir.array<10xf32>>, !fir.shape<1>) -> !fir.ref<!fir.array<10xf32>>
%4 = acc.create varPtr(%3 : !fir.ref<!fir.array<10xf32>>) -> !fir.ref<!fir.array<10xf32>> {name = "arr"}
%5 = acc.declare_enter dataOperands(%4 : !fir.ref<!fir.array<10xf32>>)
```
the acc.declare_enter itself is enough to identify when the data region
starts.
The cost model in the past returned -1 for unknown costs, but over time
this has largely been removed. This cleans up some of the uses that have
remained. It uses 0/free for the cost of an insert and 1/basic for the
cost of anything that is unknown.
This patch adds the following Dense Math Facility 16-bit half-precision
floating-point calculation instructions: dmxvf16gerx2, dmxvf16gerx2pp,
dmxvf16gerx2pn, dmxvf16gerx2np, dmxvf16gerx2nn, pmdmxvf16gerx2,
pmdmxvf16gerx2pp, pmdmxvf16gerx2pn, pmdmxvf16gerx2np, pmdmxvf16gerx2nn,
along with their corresponding intrinsics and tests.
While working on #134845 I was trying to understand the difference of
how the reinterpret_cast and subview operators see the input memref, but
it was not clear to me.
I did a couple of experiments in which I learned that the subview takes
into account the view of the input memref to create the view of the
output memref, while the reinterpret_cast just uses the underlying
memory of the input memref.
I thought it would help future readers to see these two experiements as
examples in the documentation to quickly figure out the difference
between these two operators.
@matthias-springer
@joker-eph
@sahas3
@Hanumanth04
@dixinzhou
@rafaelubalmw
---------
Co-authored-by: Ivan Garcia <igarcia@vdi-ah2ddp-178.dhcp.mathworks.com>
This PR introduces a Metadata Node Kind allowlist. The purpose is to
prevent newer Metadata Node Kinds to be used and inserted into the
outputted DXIL module. Only the metadata kinds that are accepted in the
DXIL Validator are on the allowlist. The Github DXC validator doesn't
support these newer Metadata Node Kinds, so we need to filter them out.
We introduce this restrictive allowlist into LLVM and strip all metadata
that isn't found in the list.
The accompanying test would add the `llvm.loop.mustprogress` metadata
node kind, but thanks to the allowlist, filters it out, and so the
whitelist is proven to work.
The test also has two separate metadata kinds that are on the allowlist,
and remain after the DXIL Prepare pass.
