dev-handbook: Remove reference to kgdb in EOL FreeBSD
kgdb exists in the base system only in FreeBSD 11 and earlier, which is
well past EOL. Remove the reference, leaving only a reference to the
kgdb port or package from devel/gdb.
Sponsored by: The FreeBSD Foundation
[KnownBits][SelectionDAG] Add KnownBits::clmul. Support trailing bits. NFC (#177517)
Borrow the known trailing bits logic from KnownBits::mul, but using
APIntOps::clmul.
[RISCV] Select (clmul (zext_inreg X, i32), (zext_inreg X, i32)) as (clmulh (slli X, 32), (slli X, 32)). (#177429)
Without Zba. We do the same for MUL->MULHU without Zba.
AMDGPU: Use generic legality checks instead of checking subtarget feature
Avoid checking predicates on AMDGPUSubtarget when possible. Also add a couple
of tests for the ctlz combine where ffbh isn't legal. I'm not sure what
the point of the previous check was.
[LLVM] Update assert to removed unused variable warning. (#177632)
Remove the variable definition and move the function call directly into
the assert statement. Otherwise builds with -Werror that don't use
asserts would fail.
[Support] Avoid misguided FreeBSD hack (#177508)
FreeBSD doesn't do anything wrong here, it just happens to define and
use a struct thread in its own headers. The problems arise because here
in LLVM we have using namespace llvm prior to including system headers,
which is bad practice for precisely this reason. If we instead play by
the rules and defer our using namespace llvm until after we've included
the system headers then we no longer need this hack.
This hack is particularly problematic by being conditional on
__FreeBSD__ as of 9093ba9f7ee5 ("[Support] Include Support/thread.h
before api implementations (#111175)"), since on non-FreeBSD
Threading.inc can reference anything in Support/thread.h, only causing
errors on FreeBSD, which is precisely what happened in 64be34c562a2
("Enable using threads on z/OS (#171847)").
By deferring the using namespace llvm until after Threading.inc is
included there may be build failures introduced on untested platforms
due to needing to replace unqualified identifiers with qualified ones by
prepending llvm::.
AMDGPU: Ignore type legality in isFAbsFree (#177630)
This treats it as free on targets without legal f16. This
matches the existing logic in fneg, and they should be the same.
The test changes are mostly neutral with a few improvements.
pc64 - First hacky attempt at implementing a deep MWAIT sleep inhibitor.
This is needed by i915(4), to make its DisplayPort code reliable when deep
MWAIT C-States might be used. Since the i915(4) code is not aware of the
CPU core that its interrupt is routed to, we have to pessimistically inhibit
deep MWAIT sleeps on all cores.
This adds a very basic cpu_inhibit_deep_sleep() function to the pc64 platform.
cpu_inhibit_deep_sleep(1) increments a counter by 1, and
cpu_inhibit_deep_sleep(0) decrements that counter. And a positive value in
the counter inhibits deep MWAIT C-States on Intel hardware. Since modern AMD
hardware uses fully autonomous power-saving state selection, and no MWAIT
for idling, this function has no effect on AMD right now.
drm - Improve hrtimer. Handle HRTIMER_RESTART, and use a precise timer.
This should fix powersaving in i915(4), and the more precise timeout should
also help powersaving a bit in some cases.
i915.4 - Remove mention of enable_execlists and disable_aux_irq tunables.
These have been gone from the code for a while. This just syncs documentation.
[HIP] Pass HIP library directly and refactor (#176019)
Summary:
Currently we pass `-L` and `-l` to get the HIP library. Because we are
attached to a single HIP installation it's far better to pass it by
filename. This is because the `-L` could be out of order with other user
libraries and those could override it. If someone uses HIP with a
specific ROCm installation they most likely want that library, otherwise
incompatibilities can occur. This is still overridable with command line
flags if users want to pass a different one for some reason.
This PR also refactors the handling to be more generic for future
additions.
