[VPlan] Consistently use MinOrMax* in VPlanConstruction transforms (NFC)
Make sure variables/functions consistently use MinOrMax*, as suggested
in https://github.com/llvm/llvm-project/pull/170223. Split off from the
PR.
x11-toolkits/thentenaar-motif*: Switch to new upstream
Tim Hentenaar <tim at hentenaar.com> emailed me to announce he is resuming
Motif development. The first step is to point to the new upstrewam.
thentenaar-motif*: Repocopy open-motif* to thentenaar-motif*
A fork of open-motif is now being developed. It will eventually replace
open-motif but development is too active to replace open-motif for fear
of breaking many ports.
[clang][RISCV] Add big-endian RISC-V target support (#165599)
We proceeded with frontend/clang changes, until we figure out how ABI
for BE should look like. Once it is final, we will proceed with codegen
changes.
In this patch several things addressed:
- Define riscv32be/riscv64be target triples
- Set correct data layout for BE targets
- Handle BE-specific ABI details
- Emit warning for BE case since it is still experimental
[SelDag] Use use BoolVT size when expanding find-last-active, if larger. (#175971)
On some targets, BoolVT may have been widened earlier. In those cases,
choosing StepVT to be smaller can cause crashes when widening the
mis-matched select. Without the fix, the new test
@extract_last_active_v4i32_penryn crashes when trying to widen.
It also improves codegen for other cases.
PR: https://github.com/llvm/llvm-project/pull/175971
pmap functions send various TLB shootdown operations by IPI to other cpus.
A lock is grabbed to serialize this. Then recipient cpus get sent an IPI
demanding this work. The lock is reused as a counter of cpus doing the work,
and each cpu's IPI handler decrements the counter.
The local cpu can do some operations in the parallel, before verifying
the TLB operations have completed in pmap_tlb_shootwait() which spins
for the counter to reach 0. But the counter is also a lock, and 0
means other cpu can grab it. So if the latency for the local work
exceeds the latency on the recepient cpus, the "counter-lock" can be
grabbed by a different cpu for its own TLB shootdown operations. The
original cpu will now spin waiting for this second cpu's work to
finish, creating pmap function latency.
To fix this, I create per-cpu counters which are seperate from the lock.
The IPI functions written in asm now decrement this per-cpu counter, and
when it reaches 0, the shared lock is cleared allowing another cpu to
being shootdowns tracked by its own per-cpu counter. The waiting
function only spins on the correct per-cpu counter.
As a bonus, the lock (and new variable indicating the shooting cpu)
are now in cache-aligned.
[2 lines not shown]
lang/gcc6-aux: update to GCC-6.5.0, regen bootstraps (+)
Original MASTERSITE is dead now and bootstraps is not available anymore.
Update GCC components from 6.4.1 to 6.5.0, latest 6.x release.
Regen all ada boostraps to 6.5.0 release, made all for minimal supportted FreeBSD release, 13.5.
Point WWW to original jmarino's ada development environment, https://github.com/jrmarino/draco
PR: 292414
MFH: 2026Q1
(cherry picked from commit 0286baf75e6a15721015ae1b4838bcbd6afdc218)
lang/gcc6-aux: update to GCC-6.5.0, regen bootstraps (+)
Original MASTERSITE is dead now and bootstraps is not available anymore.
Update GCC components from 6.4.1 to 6.5.0, latest 6.x release.
Regen all ada boostraps to 6.5.0 release, made all for minimal supportted FreeBSD release, 13.5.
Point WWW to original jmarino's ada development environment, https://github.com/jrmarino/draco
PR: 292414
MFH: 2026Q1