[Delinearization] Limit the scope of collecting strides (#206688)
Similar to #204145, this patch limits the scope of stride collection
performed by `SCEVCollectStrides`. Before this change, it traversed all
kinds of SCEV expressions. For example, given the expression `{(sext
{0,+,%x}),+,%y}`, it would collect `%x` and `%y` as strides, even though
their integer types (bit widths) differ.
Collecting strides whose types differ from that of the original
expression is not particularly meaningful, because such strides probably
cannot contribute to a successful delinearization of the entire
expression. Furthermore, #204146 revealed that they can trigger
undesirable calls to `SCEVDivision::divide`. Currently, when such
strides are collected, `SCEVDivision::divide` may be invoked on
expressions with different integer types, resulting in division attempts
between incompatible types.
This patch does not add any tests because I could not find a case where
it changes the result. I also did not mark it as NFCI, since it changes
some debug output. However, I believe it does not affect the outcome of
the delinearization itself.
[lldb] Fix surprising return values from Log::Enable/DisableChannel (#205561)
Fixes #202615, and the fact that the command "log enable" was not being
marked as a failure in some situations where it printed errors.
The root of this is some unexpected behaviour from Log::EnableChannel
and Log::DisableChannel. They only returned false if the channel was
invalid. If any of the categories were invalid, error messages would be
generated, but EnableChannel would return true.
This is what caused lldb-server not to exit or print any error when this
happened. The lldb command "log enable" was printing the error stream
regardless of result, but the command object was never set to failed
(the same applies to DisableChannel).
To fix this I have made them do what you'd expect. Return false if any
part of the log channel or categories was not recognised.
To do that, I had to allow for GetFlags failing. So that has changed
[13 lines not shown]
[MLIR] Remove leftover field from Variadic, NFC (#176373)
There appears to be an unused field in the `Variadic` TableGen class,
introduced originally in commit
70b69c54fa8b24519cd549eec10e549471157bb8. It looks like, when removing
the associated `VariadicAtLeast` class
(bf8049dc483131365aea3d3626a2d27b5dfa92de), this field still remained.
[libomp][AIX] Rename libatomic to libcompiler_rt (#203594)
This change updates the reference from `libatomic` to `libcompiler_rt`
to match the recent renaming on AIX.
[Flang][OpenMP] Split host op and function filtering (#184786)
The function filtering pass, intended to remove host-only functions from
a target device MLIR module on an OpenMP offloading application, also
removes any remaining host operations placed within functions containing
an `omp.target` region.
One problem with this approach is that the function filtering pass runs
relatively early, so followup passes can end up introducing new host
operations that would not be caught in advance. Specifically, there is a
known case where the `LowerWorkdistribute` pass can add
`omp.target_data` operations that then trigger an assertion during MLIR
to LLVM IR translation.
By splitting the host op deletion logic into its own pass, we can delay
it to run after `LowerWorkdistribute`, preventing these transformations
from producing an invalid target device MLIR module. The logic of the
new pass and associated test have been tweaked to properly handle FIR.
Fixes #180503
net/wireguard-tools: Drop workaround for Darwin bash
On macOS, system bash is no longer used as a tool, so there's no need
to undef it. (This workaround was specific to Darwin and cited bash 3.x.)
