[clang][coverage] Introduce `hasSkipCounter` instead of `getIsCounterPair` (#178397)
The return value of `getIsCounterPair(S)` was `std::pair<bool,bool>` but
its `hasExec` wasn't used. So, introduce just the `hasSkipCounter(S)`.
It'd be better to name `getExecSkipCounterExistence` if
`std::pair<bool,bool>` would be resurrected in the future.
[RISCV] Add assertions that binary and ternary classes are being used correctly in RISCVInstrInfoP.td. NFC (#178520)
The P extension defines an 'R' bit in some encodings that when set
indicates the instruction reads the destination register.
We had some problems in the past where we weren't using the ternary
classes for these cases. This patch adds asserts to better check this.
[libc] Modular printf option (float only)
This adds LIBC_CONF_PRINTF_MODULAR, which causes floating point support
(later, others) to be weakly linked into the implementation.
__printf_modular becomes the main entry point of the implementaiton, an
printf itself wraps __printf_modular. printf it also contains a
BFD_RELOC_NONE relocation to bring in the float aspect.
See issue #146159 for context.
[VPlan] Add hidden `-vplan-print-after-all` option (#175839)
This consists of the following changes:
* Merge several overloads of `VPlanTransforms::runPass` into a single
function
to avoid code duplication.
* Add helper macro `RUN_VPLAN_PASS` to capture the transformation name
and pass it to the helper above for printing.
* Add new `-vplan-print-after-all` option (somewhat similar to existing
`-vplan-verify-each`).
* Add two empty passes `printAfterInitialConstruction`/`printFinalVPlan`
so that initial/final
VPlans would be supported in `-vplan-print-after-all`
This follows the original future plans in
https://github.com/llvm/llvm-project/pull/123640.
linuxkpi: Add tag support to radix tree
The tag is used to perform lookup in a different way.
New functions were introduced:
* to set, check and clear a tag
* to walk through a radix tree based on a given tag
Furthermore, the `radix_tree_delete()` function was modified to clear
tags on deletion.
The amdgpu DRM driver started to use this in Linux 6.10.
While here, the `radix_tree_gang_lookup()` function was added because it
is very close to `radix_tree_gang_lookup_tag()`, but it is not used by
the DRM drivers as of this commit.
Reviewed by: emaste
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D54503
(converters/orcus) Updated to 0.21.0, with asking at least gcc12
(previous commit was missing following log, sorry)
* When importing an XML document via orcus_xml, import_factory's
finalize() method was previously not called which violates the
interface contract. This version fixes it.
* added static method has_range(std::string_view stream) to both
orcus_xml and orcus_json to detect whether a given XML and JSON
document has at least one linkable range, respectively.
* added a variant of orcus::detect() function that takes a document
content and the format type to check against. This variant only
checks whether the document is of the specified type, and returns the
result as a boolean value.
* The following functions now take a binary stream containing file
content as std::string_view as opposed to the previous const char* and
size_t pair:
[14 lines not shown]
(converters/orcus) +USE_CXX_FEATURES = c++20, implying for gcc12
NetBSD/amd64 9.x fails with following line, later releases are OK.
In file included from /usr/include/g++/memory:80:0,
from ../../include/orcus/stream.hpp:13,
from stream.cpp:8:
/usr/include/g++/bits/unique_ptr.h: In instantiation of 'typename std::_MakeUniq<_Tp>::__single_object std::make_unique(_Args&& ...) [with _Tp = orcus::file_content::impl; _Args = {std::basic_string_view<char16_t, std::char_traits<char16_t> >&}; typename std::_MakeUniq<_Tp>::__single_object = std::unique_ptr<orcus::file_content::impl>]':
stream.cpp:191:44: required from here
/usr/include/g++/bits/unique_ptr.h:821:30: error: no matching function for call to 'orcus::file_content::impl::impl(std::basic_string_view<char16_t>&)'
{ return unique_ptr<_Tp>(new _Tp(std::forward<_Args>(__args)...)); }
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
interfaces: multi-dhcp6c support and custom PD association #7647
This splits off rtsold and dhcp6c into separate processes
which frees us from the restrictions of faked iterative IDs
for PD associations. For NA we simply default to 0 now.
I'm not entirely sure why we settled for a single deamon of
dhcp6c back in the day, but there are certianly downsides to
it and I don't see something that wasn't fixed in the meantime
that makes this not work.
[Github] Make libcxx-check-generated-files.yml not run in forks
This is best practice according to
https://llvm.org/docs/CIBestPractices.html. Found this when looking at
PRs on forks and saw one running for libc++.
vtnet: remove M_HASHTYPE when there is only one pair of rx/tx queue
Summary:
Doing so will let the upper layer know how to deal with software hash,
with benefits like inp_flowid can be set and m_pkthdr.flowid can be set
in output path.
Reviewed by: tuexen
Differential Revision: https://reviews.freebsd.org/D54929
In uvm_pdaemon.c 1.121, 1.122, and 1.123, two things happened:
1. The shortage target inside uvmpd_scan() / uvmpd_scan_inactive() which
used to be computed using the realtime uvmexp.free value, was replaced with a
(historic prediction) using the pre-existing pagedaemon "shortage" variable.
This means the scanner will continue work even if the system recovers
memory asyncronously and has resolved the scarcity which caused the pagedaemon
to be summoned. That's a bad idea. The code should revert to observing
realtime system conditions. We don't have a diff for that yet, but the
other concern is immediate:
2. The pre-existing calculation of the "shortage" variable was changed
significally, without verifying correct behaviour.
size += shortage;
...
shortage -= bufbackoff(&constraint, size * 2);
since bufbackoff() returns how much it did, and generally succeeds at
satisfying the full request size * 2, that is effectively "shortage =
-shortage". The scan function changes still expect a positive target
[5 lines not shown]
[mlir] Add [may]updateStartingPosition to VectorTransferOpInterface
This commit adds methods to VectorTransferOpInterface that allow
transfer operations to be queried for whether their base memref (or
tensor) and permutation map can be updated in some particular way and
then for performing this update. This is part of a series of changes
designed to make passes like fold-memref-alias-ops more generic,
allowing downstream operations, like IREE's transfer_gather, to
participate in them without needing to duplicate patterns.
[mlir][MemRef] Make fold-memref-alias-ops use memref interfaces
This replaces the large switch-cases and operation-specific patterns
in FoldMemRefAliashops with patterns that use the new
IndexedAccessOpInterface and IndexedMemCopyOpInterface, which will
allow us to remove the memref transforms' dependency on the NVGPU
dialect.
This does also resolve some bugs and potential unsoundnesses:
1. We will no longer fold in expand_shape into vector.load or
vector.transfer_read in cases where that would alter the strides
between dimensions in multi-dimensional loads. For example, if we have
a `vector.load %e[%i, %j, %k] : memref<8x8x9xf32>, vector<2x3xf32>`
where %e is
`expand_shape %m [[0], [1], [2. 3]] : memref<8x8x3x3xf32> to 8x8x9xf32,
we will no longer fold in that shape, since that would change which
value would be read (the previous patterns tried to account for this
but failed).
2. Subviews that have non-unit strides in positions that aren't being
[15 lines not shown]
[mlir] Implement indexed access op interfaces for memref, vector, gpu, nvgpu
This commit implements the IndexedAccessOpInterface and
IndexedMemCopyInterface for all operations in the memref and vector
dialects that it would appear to apply to. It follows the code in
FoldMemRefAliasOps and ExtractAddressComputations to define the
interface implementations. This commit also adds the interface to the
GPU subgroup MMA load and store operations and to any NVGPU operations
currently being handled by the in-memref transformations (there may be
more suitable operations in the NVGPU dialect, but I haven't gone
looking systematically)
This code will be tested by a later commit that updates
fold-memref-alias-ops.
Assisted-by: Claude Code, Cursor (interface boilerplate, sketching out
implementations)
[mlir][memref] Define interfaces for ops that access memrefs at an index (#177013)
This commit defines interfaces for operations that perform certain kinds
of indexed access on a memref. These interfaces are defined so that
passes like fold-memref-alias-ops and the memref flattener can be made
generic over operations that, informally, have the forms `op ... %m[%i0,
%i1, ...] ...` (an IndexedAccessOpInterface) or the form `op %src[%s0,
%s1, ...], %dst[%d0, %d1, ...] size ...` (an IndexedMemCopyOpInterface).
These interfaces have been designed such that all the passes under
MemRef/Transforms that currently have a big switch-case on memref.load,
vector.load, nvgpu.ldmatrix, etc. can be migrated to use them.
(This'll also let us get rid of the awkward fact that we have memref
transforms depending on the GPU and NVGPU dialects)
While the interface doesn't currently contemplate changing element types
(enabling, for example, writing a bf16 => u16 update to be done in
place), future extensions to allow such transformations could be worth
[7 lines not shown]
interfaces: generalise the dhcp6c_script using the new IFNAME variable #7647
Now that the new dhcp6c code is in 26.1 we can start using it.
The file was conceptually created inline via d36f0f4f62557 and before was
a single command line script... so add appropriate copyrights from that
time onward.
Many thanks to Martin for pinoeering this back in the day!
capsicum-test: Move out of contrib
Google developed the Capsicum unit test suite[1] as part of the
Capsicum-Linux[2] project, based on unit tests that existed in FreeBSD
and unit tests developed as part of the initial Capsicum-Linux port.
Capsicum-Linux was archived as of October 31, 2022 and is no longer
being maintained. FreeBSD is currently the only consumer of and
contributor to the test suite. Move the src into tests/sys/capsicum to
simplify ongoing maintenance.
The makefiles were deleted as we (continue to) use the existing bespoke
FreeBSD Makefile, and CONTRIBUTING.md was removed as the Google CLA is
no longer applicable.
[1] https://github.com/google/capsicum-test
[2] https://github.com/google/capsicum-linux
Reviewed by: asomers, oshogbo
[2 lines not shown]
