igc: Add led(4) identification support
I225 and I226 expose three programmable LED outputs. Use LED1 for
adapter identification, following the convention in DPDK. Preserve the
OEM configuration across identification requests.
Restore the OEM configuration before a device reset so an active led(4)
pattern cannot leave the output overridden across stop or detach.
The LED mode values follow the Intel I225 Software User Manual.
MFC after: 2 weeks
[TypePromotion][RISCV][ARM] Ignore the condition operand of selects. (#215685)
We don't need to promote the condition operand in order to promote a
select. It must always be an i1 type so it doesn't matter where it comes
from.
The change to pr148084.ll is a regression, but I don't think it's
directly related to select. TypePromotion is using a zero extend
promotion which makes constants that are harder to materialize and
prevents the use of `not`. This kind of thing can happen independent of
selects being involved.
[LoongArch] Fold shifted vector extract comparisons
Fold comparisons of the form:
(shl (extract_vector_elt X, I), GRLen - EleBits) ==/!= 0
into:
(extract_vector_elt X, I) ==/!= 0
When the shift amount equals `GRLen - EleBits`, the left shift only moves
the extracted element into the most significant bits without affecting
whether the value is zero. This canonicalization exposes
EXTRACT_VECTOR_ELT to later combines and enables selecting
VPICKVE2GR_* instructions directly.
igb(4): Document identification LED device nodes
The shared em(4) manual page lists only the em device-node name.
Document the /dev/led/igb* name as well.
MFC after: 2 weeks
iflib: Create led(4) devices
When a driver implements ifdi_led_func, have the framework create its
led(4) device after attach completes and the ifnet and context locks are
released.
PR: 246885
Reported by: jlduran
Reviewed by: markj
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D32389
[CIR] Fix a linking problem with a abi_tag deduced lambda (#215702)
This showed up in self build, but only happens when there is a lambda
with a deduced return type inside another lambda, that returns a type
with an abi_tag on it (std::string in this case). The problem was that
we weren't pulling our mangled name out of the cache, and instead were
re-calculating it every time. This takes code effectively-exactly from
classic-codegen an d puts it into CIRGenModule.cpp
Note the teest is a little fragile for the reproducer, so it needs to be
its own file. Also, there are some parts that are not necessary in it to
reproduce (the 'i' in particular) because this avoids us having 'padded'
lambdas, which results in a call-conv NYI. I considered disabling that,
but it is more work to go back and un-do that flag later, than to just
deal with an extra 'i' for the near future.
igc: Fix KASSERT failure when `ifconfig igc%d down`
When we invoke callout_halt(9) for rxr->rx_refill, both in
igc_stop_locked() and igc_free_receive_buffers(), we don't hold
rxr->rxr_lock.
Also, `drvctl -d igc%d` does not trigger KASSERT failure now.
iflib: Defer LED control to the device taskqueue
led(4) invokes driver callbacks while holding its mutex, including
from a callout. iflib_led_func() cannot acquire the sleepable context
lock in those contexts without causing a lock-order reversal or sleeping
from the callout.
Record the latest requested state under the iflib state lock and
enqueue the existing per-device taskqueue. The task can safely take
the context lock before invoking the driver. Coalescing requests also
avoids accumulating stale blink transitions when hardware access is
slow.
Destroy the LED device before draining its task so no new callback can
race driver detach.
MFC after: 2 weeks
[AMDGPU] Gate TBUFFER merging on relaxed OOB mode (#212695)
SILoadStoreOptimizer can combine adjacent TBUFFER accesses into a wider
typed buffer instruction. This changes the granularity of hardware OOB
handling and may affect neighboring components when an access is
partially
out of bounds.
Only allow TBUFFER load/store merging when
`amdgpu.tbuffer.oob.mode` is set to relaxed. Keep the accesses separate
when
the flag is absent, any, or strict to preserve strict OOB semantics.
Reference: https://github.com/llvm/llvm-project/pull/160922
Unpublish the segment before entering the potentially sleeping
shm_deallocate_segment() in the sys_shmat() and sys_shmctl() paths. The
remaining shm_delete_mapping() already has the right order.
From Acts1631
[libc++] Fix duplicate names in benchmarks (#215676)
A few benchmarks were using names that were reused elsewhere in the test
suite. All benchmarks must have a unique name, otherwise we can't
distinguish them in LNT.
[Flang][Driver] Override -ffast-math floating point contraction with -ffp-contract= (#213574)
This patch allows overriding the floating point contract settings
implied by -ffast-math by explicitly specifying -ffp-contract=. The
final floating point contract mode follows the usual last-flag-wins
behavior. In addition, -fno-fast-math only cancels the effects of
-ffast-math and preserves any explicitly specified -ffp-contract=
setting.
A warning is emitted when an explicit -ffp-contract= option overrides
the floating point contract mode implied by -ffast-math.
This behavior is consistent with Clang.
[CIR] Record target-cpu and target-features on function declarations (#214986)
A function declaration carried no CPU or feature attributes. CIRGen set
them from `setNonAliasAttributes`, which runs only for a definition,
where classic CodeGen sets them from `ConstructAttributeList` for a
declaration too. We now set them properly in `constructAttributeList`
alongside the other non-call-site attributes.
Recording them on a declaration exposes a second bug. When a function is
declared first and defined later with a `target` attribute,
`setNonAliasAttributes` wrote the definition's values over the
declaration's rather than replacing them, so a `tune-cpu` that the
`target` attribute suppresses survived. It now clears the three
attributes before writing, which is safe because
`getCPUAndFeaturesAttributes` resolves the most recent declaration, so
its result supersedes anything an earlier one wrote.
Assisted-by: Cursor / claude-opus-5
lit/reports.py: Make Py3.8-compatible (for #211066) (#215554)
I know py3.8 is slightly old. That said;
- llvm/CMakeLists.txt restricts the bottom version as 3.8
- This is not a functionally-critical change
I won't object further discussions if version upgrade would be required.
