[AMDGPU] Fix refactoring mishap (#216974)
We ended up calling getAllocatedNumVGPRBlocks with the arguments in the
wrong order - it should take the number of VGPRs first, and then the
size of a dynamic VGPR block.
Assisted-by: Claude
[VPlan] Append recipes created via builder to worklist
The previous PR appended the top most created recipe to the worklist, and this PR extends it to any other nested recipes that were created, similar to InstCombine.
This removes the header mask in a good few more places on RISC-V as measured on SPEC CPU 2017, e.g. for the following loop:
```c
long f(const int *p, const int *q, long n) {
long a = 0, b = 0;
for (long i = 0;; i++) {
if (p[i] && q[i]) { a += i; b += i; }
if (i + 1 == n) break;
}
return a + b;
}
```
Before:
[49 lines not shown]
[VPlan] Make simplifyRecipe more like InstCombine
Most combines in simplifyRecipe RAUW a value, but not all of them erase the old recipe.
Unify them and bring it in line with InstCombine by having it return a VPValue, which simplifyRecipes can then call RAUW with, and automatically erase the old recipe.
Similarly to InstCombine, combines that modify a recipe should return the same recipe.
[VPlan] Process simplifyRecipes in a worklist
This brings simplifyRecipes further in line with InstCombine, and asides from unlocking more simplifications it also helps avoid spurious test churn whenever passes are moved around simplifyRecipes.
For now just push the new recipe onto the worklist, not its users.
This uses a post order traversal so we maintain the same simplification order as before.
I've gone through and checked every simplification we do is a canonicalisation that converges, and I checked on llvm-test-suite + SPEC CPU 2017 in various configurations that we don't hit any cycles.
[VPlan] Make simplifyRecipe more like InstCombine
Most combines in simplifyRecipe RAUW a value, but not all of them erase the old recipe.
Unify them and bring it in line with InstCombine by having it return a VPValue, which simplifyRecipes can then call RAUW with, and automatically erase the old recipe.
Similarly to InstCombine, combines that modify a recipe should return the same recipe.
[Clang][RISCV] Allow three SiFive CLIC interrupt arguments (#216159)
The SiFive CLIC interrupt values may be combined with each other and
with the machine value, but the interrupt attribute previously accepted
at most two arguments.
This commit allows three arguments for the combination of machine,
SiFive-CLIC-preemptible, and SiFive-CLIC-stack-swap.
Fixes #216138
[X86] isTargetShuffleEquivalent - only use "known zero" element if its known never poison/undef as well (#217030)
We're starting to hit cases where we've used AND/ANDNP masking to zero
out vector elements, but SimplifyDemandedElts assumes the element is
unused, folds to poison and then later folds AND(poison,0) -> poison.
This needs a more thorough cleanup of a number of x86 folds that do this
(similar to #215538), but that would result in a great deal of churn,
and it looks like a #214388 fix requires backporting to 23.x.
So initially I'm taking the approach that @xyyy1420 found so we can get
this backported and I can then address the issue more thoroughly in
trunk. I'm not convinced that this will address all poison cases, but
I'm reluctant to attempt a larger backport patch.
Fixes #214388
[VPlan] Append recipes created via builder to worklist
The previous PR appended the top most created recipe to the worklist, and this PR extends it to any other nested recipes that were created, similar to InstCombine.
This removes the header mask in a good few more places on RISC-V as measured on SPEC CPU 2017, e.g. for the following loop:
```c
long f(const int *p, const int *q, long n) {
long a = 0, b = 0;
for (long i = 0;; i++) {
if (p[i] && q[i]) { a += i; b += i; }
if (i + 1 == n) break;
}
return a + b;
}
```
Before:
[49 lines not shown]
[VPlan] Process simplifyRecipes in a worklist
This brings simplifyRecipes further in line with InstCombine, and asides from unlocking more simplifications it also helps avoid spurious test churn whenever passes are moved around simplifyRecipes.
For now just push the new recipe onto the worklist, not its users.
This uses a post order traversal so we maintain the same simplification order as before.
I've gone through and checked every simplification we do is a canonicalisation that converges, and I checked on llvm-test-suite + SPEC CPU 2017 in various configurations that we don't hit any cycles.
[VPlan] Make simplifyRecipe more like InstCombine
Most combines in simplifyRecipe RAUW a value, but not all of them erase the old recipe.
Unify them and bring it in line with InstCombine by having it return a VPValue, which simplifyRecipes can then call RAUW with, and automatically erase the old recipe.
Similarly to InstCombine, combines that modify a recipe should return the same recipe.
www/opengist: Update to v1.14.0
- Remove assets dir, they are already bundled in the binary
- Fix the broken rc service that would not shut down correctly
- Move the pidfiles to /var/run/ to avoid needing to create a dir
- Use the prebuilt frontend assets published upstream, dropping the
npm build dependency
- Enable aarch64
Reviewed by: fox
Differential Revision: https://reviews.freebsd.org/D58255
[LV] Make operand bundle test not constant-foldable/dead. NFC (#217253)
The test looks like it was originally added to check that operand
bundles were preserved, but the libcall is constant folded away and made
dead. Later PRs may end up removing this, see the conversation in
https://github.com/llvm/llvm-project/pull/212968#discussion_r3702373769
evbarm/am18xx: sdmmc driver
A first version of the SD card driver for the TI am1808. The driver works fine, but the performance is lower than expected.
litestream: Update to 0.5.16
pkgsrc changes:
- Bump modernc.org/sqlite to version that brings back NetBSD/amd64
support
Changes:
Too long to include, sorry, please see:
<https://github.com/benbjohnson/litestream/releases>
evbarm/ti_edma: clear events before transfer
The sdmmc controller on the am18xx fires dma events even in PIO mode. Clear these event before starting a DMA transfer.
mk: Introduce support for ULIMIT_PRECMD.
While this has potential to run any pre-command, it is primarily useful as a
hook to insert ulimit(1) commands that will apply to shell commands, hence
the name.
In bulk builds there will occasionally be packages that end up spinning on
CPU and hanging the build until the user has a chance to kill the process.
For some builds this is desirable so that the issue can be debugged, but for
others the user may prefer to avoid having to interact with the build to get
it to complete, in which case they can set this to e.g. "ulimit -S -t 3600".
[Clang][NFC] Remove unused constructor of ASTTemplateArgumentListInfo (#217200)
It turns out that its only client VarTemplateSpecializationDecl has
stopped copying template arguments since 2024, see
12028373020739b388eb2b8141742509f1764e3c
