Skip to content

Conversation

@z1-cciauto
Copy link
Collaborator

No description provided.

ashgti and others added 20 commits October 31, 2025 13:33
Noticed this while looking into test stability that the 'entry' stop
reason is not triggering correctly. This should ensure we correctly
trigger the 'entry' stop reason when launching a process with
`"stopOnEntry": true`. I've also updated the tests to ensure we receive
the 'entry' stop reason to catch this regression.
This is largely based off of llvm#143615, but for the DirectX target which
is still in experimental.
This was broken by 5322fb6. Update the
test to be a little more resilient to flaky failures and to pass after
those changes. We should probably delete this now that we have MIR2Vec,
but punting that for now.
Small change to use (what I think is) a better practice -- we were using
the `m_indexed` bool member to make sure we called `Index()` once, but
we should just use `std::once`! This change shouldn't affect
functionality.

This change may also make concurrent access to `Index()` thread-safe,
though the ManualDWARFIndex API isn't completely thread-safe due to
`Decode()`. I'm not sure if ManualDWARFIndex was ever intended to be
thread-safe.

Test Plan:

`ninja check-lldb`

Tested basic debugging workflow of a couple of large projects I had
built. Basically:
```
(lldb) target create <project>
(lldb) b main
(lldb) r
(lldb) step
... 
```

I A/B tested the performance of launching several modules with parallel
module loading and didn't observe any performance regressions.

---------

Co-authored-by: Tom Yang <toyang@fb.com>
… of PATCHPOINT/STACKMAP. (llvm#165926)

This is consistent with other promotion, but causes negative constants
to be sign extended instead of zero extended in some cases.

I guess getNode and type legalizer are inconsistent about what
ANY_EXTEND of a constant does.
If the laternate operation is more stricter than the main operation, we
cannot rely on the analysis of the main operation. In such case, better
to avoid doing the analysis at all, since it may affect the overall
result and lead to incorrect optimization

Fixes llvm#165878
…in bazel build (llvm#165930)

It will otherwise introduce a circular dependency XeGPUDialect ->
XeGPUUtils -> XeGPUDialect.
…5933)

A remaining failing one, under SimplifyCFG (which is pass that we did fix) is covered in llvm#165931
…urnSwitchRangeIntoICmp` (llvm#165931)

PR llvm#161000 introduced a bug whereby the IR would become invalid by having an unconditional branch have `!prof`​attached to it. This only became evident in PR llvm#165744, because the IR of `test/Transforms/SimplifyCFG/pr165301.ll`​was simple enough to both (1) introduce the unconditional branch, and (2) survive in that fashion until the end of the pass (simplifycfg) and thus trip the verifier.
Some of the examples contain typos; some of them use outdated assembly format,
and some annotations are missing. This is the best effort to keep them
"parsable" (assuming that most of the types are already defined).
Split off from llvm#156262.

Similar to VPRegionBlock::getCanonicalIV, add helper to get the type of
the canonical IV, in preparation for removing VPCanonicalIVPHIRecipe.

PR: llvm#164127
@z1-cciauto z1-cciauto requested a review from a team November 1, 2025 03:07
@z1-cciauto
Copy link
Collaborator Author

@z1-cciauto
Copy link
Collaborator Author

@ronlieb ronlieb closed this Nov 1, 2025
@ronlieb ronlieb reopened this Nov 1, 2025
@z1-cciauto
Copy link
Collaborator Author

@ronlieb ronlieb closed this Nov 1, 2025
@ronlieb ronlieb reopened this Nov 1, 2025
@z1-cciauto
Copy link
Collaborator Author

@z1-cciauto z1-cciauto merged commit b152df7 into amd-staging Nov 1, 2025
19 checks passed
@z1-cciauto z1-cciauto deleted the upstream_merge_202510312307 branch November 1, 2025 13:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.