InstCombine: Handle fsub in SimplifyDemandedFPClass (#175852)
alive2 fails on some of the tests, but this is due to existing
folds in instsimplify and
https://github.com/AliveToolkit/alive2/issues/1273
InstCombine: Fold known-qnan results to a literal nan
Previously we only considered fcNan to fold to qnan for canonicalizing
results, ignoring the simpler case where we know the nan is already
quiet.
AMDGPU: Disable scheduler mfma rewrite stage by default for now (#177624)
Currently generating an excess number of copies. Turning it off to avoid
churn for other developers.
[libc++] Automatically detect the libc++ hardening mode from the test suite (#172505)
This prevents hardcoding the hardening mode via compiler flags, and
allows testing what the default hardening mode is on platforms that set
it to something that isn't `none`. Otherwise, a platform setting a
default (which is done via -DLIBCXX_HARDENING_MODE=mode at CMake
configuration time) would end up passing `-D_LIBCPP_HARDENING_MODE=mode`
to the compiler, which does not allow checking what the default mode is.
[LV] capture branch weights for constant trip counts (#175096)
When a vectorized loop has constant trip, it's important to update the
profile information accordingly. Hotness analysis will only look at
profile info.
For example, in the `tripcount.ll` test, without producing the profile
info, in the `const_trip_over_profile` function, the BFI of the
`vector.body` would be 32 (this is the expected value when synthetic
branch weights are used, in loops). The real value is 250. The
`for.body`value was _very_ incorrect before, too (and detrimentally so,
as it would have appeared as "very hot" when it wasn't):
The table below was obtained by printing BFI in the RUN: command, i.e.
`build/bin/opt < llvm/test/Transforms/LoopVectorize/tripcount.ll
-passes="loop-vectorize,print<block-freq>"
-loop-vectorize-with-block-frequency -S -o /dev/null`. Showing only the
`float` value, i.e. the BFI relative to the function entry BB.
[15 lines not shown]
[libc++][NFC] Simplify some `optional.observe` tests (#175682)
- Collapse the different ref/const-qualifier `operator*`, `operator->`
and `value()` tests since they were all very similar to each other
- Refactor them to be inline with the current testing style
netinet6: free in6_ifextra with epoch_call(9)
This is expected to fix the old in6_selecthlim() panics. The nature of
the panic is that a packet sending thread will obtain the struct ifnet
pointer locklessly and then pick the if_inet6 pointer from it and
dereference it. While the struct ifnet is freed via epoch_call(9), the
struct in6_ifextra until this change was not. For the forwarded packets,
or locally originated non-TCP packets we were probably safe due to the old
if_dead trick. But locally originated TCP packets may dereference
in6_ifextra via direct call into in6_selecthlim() from the tcp_output(),
before ip6_output().
NB: hypothetically a similar problem also applies to IPv4's if_inet pointer,
but there are no known panics, yet.
PR: 279653
Reviewed by: tuexen
Differential Revision: https://reviews.freebsd.org/D54728
netinet6: embed struct mld_ifsoftc into struct in6_ifextra
In mld_domifdetach() don't search the global list.
Reviewed by: tuexen
Differential Revision: https://reviews.freebsd.org/D54727
[lldb] Fix setting CanJIT if memory cannot be allocated (#176099)
When a server is unable to allocate memory for the `_M` packet, it may
respond with an error code. In this case,
`GDBRemoteCommunicationClient::AllocateMemory()` sets
`m_supports_alloc_dealloc_memory` to `eLazyBoolYes`; `eLazyBoolNo` is
only used if the server cannot handle the packet at all. Before this
patch, `ProcessGDBRemote::DoAllocateMemory()` checked this flag and
returned `LLDB_INVALID_ADDRESS` without setting an error, which caused
`Process::CanJIT()` to set `m_can_jit = eCanJITYes`, resulting in
`IRMemoryMap::FindSpace()` attempting to allocate memory in the inferior
process and failing. With the patch,
`ProcessGDBRemote::DoAllocateMemory()` returns an error and `m_can_jit`
is set to `eCanJITNo`.
Example debug session:
```
(lldb) platform connect...
(lldb) file test
[8 lines not shown]
netinet6: store ND context directly in struct in6_ifextra
Stop using struct nd_ifinfo for that, because it is an API struct for
SIOCGIFINFO_IN6. The functional changes are isolated to the protocol
attach and detach: in6_ifarrival(), nd6_ifattach(), in6_ifdeparture(),
nd6_ifdetach(), as well as to the nd6_ioctl(), nd6_ra_input(),
nd6_slowtimo() and in6_ifmtu().
The dad_failures member was just renamed to match the rest. The M_IP6NDP
malloc(9) type declaration moved to files that actually use it.
The rest of the changes are mechanical substitution of double pointer
dereference via ND_IFINFO() to a single pointer dereference. This was
achieved with a sed(1) script:
s/ND_IFINFO\(([a-z0-9>_.-]+)\)->(flags|linkmtu|basereachable|reachable|retrans|chlim)/\1->if_inet6->nd_\2/g
s/nd_chlim/nd_curhoplimit/g
Reviewed by: tuexen, madpilot
Differential Revision: https://reviews.freebsd.org/D54725
netinet6: use in6_ifmtu() instead of IN6_LINKMTU() macro
There should be no functional change. If there are any performance
concerns with a function call, with the future changes, that would move
ND6 bits into in6_ifextra, this function would be easily inline-able.
Reviewed by: tuexen
Differential Revision: https://reviews.freebsd.org/D54724
