[IR][FunctionAttrs] Clarify memory effects of atomics (#193768)
FunctionAttrs was treating atomic instructions, including with ordering
stronger than monotonic, as only reading/writing their operand.
I don't think doing this is correct, because we model the ordering
constraints of synchronizing atomics via reading/writing "all" memory.
So e.g. if you have a function with a release store on an argument,
marking it as argmem-only is wrong, because that would permit reordering
accesses to other locations around it. (What this PR is doing is not
*sufficient* to model this correctly due to the fence-like effects on
not-yet-escaped memory, but it brings us closer to correctness.)
I initially tried to implement mayReadFromMemory() and
mayWriteToMemory() on top of getMemoryEffects(), but this caused
significant compile-time regressions, so I've kept the logic duplicated.
[VPlan] Remove redundant vp_merge pattern. NFC (#200116)
m_RemoveMask still matches even if there's no other mask combined, we
just need to check if Mask is null.
[VPlan] Don't use Ingredient to get type in VPWidenMemoryRecipe (NFC) (#200049)
The scalar load/store type is already available on the recipe: load
recipes inherit from VPSingleDefRecipe and expose it via
getScalarType(); store recipes can derive it from the stored value's
type via VPTypeAnalysis.
This migrates a number of lookups to be based on information already
available in VPlan directly.
[GlobalISel] Replace `GIM_CheckFeatures` with `GIM_Try_CheckFeatures` (#198461)
This has two benefits. First, it slightly reduces the size of the match
table.
Secondly, if the target feature is not present, we can directly go to
the fail
case, instead of having to do another loop of the interpreter, speeding
up
rejection of rules that do not have the required target feature.
We could do the same with CheckSimplePredicate but it's less used (only
in the combiners I think)
so it is less of a priority.
```
FILE OLD NEW DIFF% SAME?
---- ------- ------- ----- -----
AArch64GenGlobalISel.inc 192681 185938 -3,5% no
AArch64GenPostLegalizeGICombiner.inc 4457 4457 0,0% yes
[5 lines not shown]
The extended nexthop capability only works with 'fib-update no'
enfoce this in the parser.
Right now there is no FIB support for IPv6 nexthops for IPv4 routes.
Both the bgpd kroute.c code and the OpenBSD network stack are not ready
for this. This feature is currently only used to allow some IXP to play
with RFC8950 so no FIB support is fine for that use case.
Protect other people from tripping over this thinking there is full support.
Issue brought up by a report from 7Asecurity
OK tb@
[mlir][spirv] Add SPIR-V NonSemantic.Graph.DebugInfo (#199519)
Add serialization and deserialization support for the SPIR-V
NonSemantic.Graph.DebugInfo.1 extended instruction set used by ARM graph
modules.
When debug info emission is enabled, serialize DebugGraph,
DebugOperation,
and DebugTensor records for graph objects, TOSA operations, graph
tensors,
and tensor constants. Emit the records after the SPIR-V objects they
reference, and make DebugOperation point at the DebugGraph result id.
Deserialize these records back into MLIR locations and diagnose
malformed
or undefined debug-info references.
Enable SPV_KHR_non_semantic_info in the default TOSA-to-SPIR-V target
environment so debug info can be emitted by default.
[7 lines not shown]
lpd: Avoid buffer overflow when sending a job
When forwarding a print job to a remote server, we could overflow the
command buffer if a control or data file had a very long name.
MFC after: 1 week
Reported by: Joshua Rogers <joshua at joshua.hu>
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D57184
(cherry picked from commit f2c7c5f94803b67a9a6af625d4fc8882d2afda6c)
lpd: Restore ability to specify a port number
This has been broken since IPv6 support was added in 2000. We would
validate the port number (which had to be a port number, but can now
also be a service name) and then ignore it.
MFC after: 1 week
Fixes: 08829865f659 ("IPv6 support for lpr.")
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D57181
(cherry picked from commit c0cae7d8da50daa87af4cd6d7c9a2043343b506f)
lpr: Add deprecation notice
These programs require elevated privileges to work and have not seen
regular maintenance in decades. Unless someone steps up and overhauls
them, we will have to remove them before 16.0. Better-maintained
alternatives are available in ports (print/cups, sysutils/LPRng).
MFC after: 3 days
(cherry picked from commit d57dee7ab66f60537b557cb602be194e3eed253d)
lpd: Avoid buffer overflow when sending a job
When forwarding a print job to a remote server, we could overflow the
command buffer if a control or data file had a very long name.
MFC after: 1 week
Reported by: Joshua Rogers <joshua at joshua.hu>
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D57184
(cherry picked from commit f2c7c5f94803b67a9a6af625d4fc8882d2afda6c)
lpd: Restore ability to specify a port number
This has been broken since IPv6 support was added in 2000. We would
validate the port number (which had to be a port number, but can now
also be a service name) and then ignore it.
MFC after: 1 week
Fixes: 08829865f659 ("IPv6 support for lpr.")
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D57181
(cherry picked from commit c0cae7d8da50daa87af4cd6d7c9a2043343b506f)
security/infisical-cli: add new port for the official Infisical CLI
The Infisical CLI is a powerful command-line tool for secret management
that allows you to:
- Inject secrets into applications and development workflows
- Scan for secret leaks in your codebase and git history
- Export secrets to various formats (dotenv, JSON, YAML)
- Authenticate with Infisical Cloud or self-hosted instances
- Integrate with CI/CD pipelines and Docker containers
