[AArch64] Lower FPR register moves to zero cycle NEON (#153158)
[AArch64] Lower FPR register moves to zero cycle NEON
Lower FPR64, FPR32, FPR16, FPR8 register moves into NEON moves if the
target supports zero cycle move for NEON but not for the narrower
classes.
Adds a subtarget feature called FeatureZCRegMoveFPR128 that enables to
query wether the target supports zero cycle reg move for FPR128 NEON
registers, and embeds it into the appropriate processors.
Includes lowering test cases, and specializes check prefixes.
vtnet: fix computation of sysctl variables
Fix the aggregation of the interface level counters
* dev.vtnet.X.tx_task_rescheduled,
* dev.vtnet.X.tx_tso_offloaded,
* dev.vtnet.X.tx_csum_offloaded,
* dev.vtnet.X.rx_task_rescheduled,
* dev.vtnet.X.rx_csum_offloaded, and
* dev.vtnet.X.rx_csum_failed.
Also ensure that dev.vtnet.X.tx_defrag_failed only counts the number
of times m_defrag() fails.
While there, mark sysctl-variables used for exporting statistics as
such (CTLFLAG_STATS).
Reviewed by: Timo Völker
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D51999
[Headers][X86] Allow integer/fp absolute intrinsics to be used in constexpr (#154662)
Fixes #153556.
In addition, four supporting intrinsics were also updated to constexpr
and tested, as they are directly used by the above intrinsics:
- _mm512_mask_and_epi64
- _mm512_mask_and_epi32
- _mm_and_epi32
- _mm256_and_epi32
Co-authored-by: Simon Pilgrim <llvm-dev at redking.me.uk>
[llvm-lto2] Added version command for llvm-lto2 (#148866)
Previously, the only way to check version for llvm-lto2 was to add
version as a subcommand: `llvm-lto2 run --version`. This adds version as
a main command for llvm-lto2 for more intuitive access.
You can now check version with the command `llvm-lto2 --version`.
MC: Fix NOP insertion between fused instructions that breaks macro fusion (#155784)
In the
https://github.com/llvm/llvm-project/commit/39c8cfb70d203439e3296dfdfe3d41f1cb2ec551
patch, getOrCreateDataFragment was optimized by eagerly allocating an
empty fragment when adding a fragment with a variable-size tail. This
means that in this case the current MC fragment is no longer the one
where the instruction was inserted, and the check
`PendingBA && PendingBA->getNext() == OS.getCurrentFragment()` fails,
since CurrentFragment is now the empty fragment instead of the fragment
containing the instruction.
`PendingBA -> Fragment with a variable-size tail (contains previous
instruction) -> CurrentFragment (newly allocated empty fragment)`
This breaks the macro-fusion logic because it incorrectly assumes
another fragment has been inserted between the fused instructions.
Fixes https://github.com/llvm/llvm-project/issues/155045
#155316 Reland
