[scudo] Use setenv instead of putenv in ScudoCombinedTest.ZeroOnDeallocEnabledAndFlag (#173423)
This solves a stack-use-after-scope reported by AddressSanitizer within
the unsetenv call at end of the test, due to the "Options" buffer, that
we allocate on the stack, having already gone out of scope.
Unlike putenv, which stores the pointer to the passed string directly in
the environment, setenv creates an internal copy.
[libc++][ranges] Applied `[[nodiscard]]` to `owning_view`, `ref_view` (#173708)
`[[nodiscard]]` should be applied to functions where discarding the
return value is most likely a correctness issue.
- https://libcxx.llvm.org/CodingGuidelines.html
- https://wg21.link/range.all
Towards #172124
[InstCombine] Drop range metadata when simplifying `fshl` with demanded bits (#173864)
InstCombine may rewrite `llvm.fshl` operands when simplifying based on
demanded bits, which can invalidate previously attached return value
constraints. Except from range attribute, `!range` metadata could also
be not dropped after operand rewriting, leading to stale
poison-generating metadata and potential miscompilations.
This patch drops poison-generating annotations when `fshl` operands are
simplified, ensuring that `!range` metadata is cleared consistently with
return attributes.
Alive2 proof: https://alive2.llvm.org/ce/z/EVUvY6
Fixes #173793
InstCombine: Handle exp/exp2/exp10 in SimplifyDemandedFPClass (#173432)
I'm working on optimizing out the tail sequences in the
implementations of the 4 different flavors of pow. These
include chains of selects on the various edge cases.
Related to #64870
InstCombine: Handle exp/exp2/exp10 in SimplifyDemandedFPClass
I'm working on optimizing out the tail sequences in the
implementations of the 4 different flavors of pow. These
include chains of selects on the various edge cases.
Related to #64870
[AMDGPU] Have VCC as a first-class member of the SGPR pool.
Add VCC and tuples using VCC to SGPR register classes.
We already support VCC as an allocatable register for 32-bit SGPR
operands, so it seems most natural to support it for register
tuple operands as well.
s106/s107 are still not allowed as aliases of vcc_lo/hi in
AsmParser.
The names given to the VCC tuples match those produced by SP3,
though it feels like there is room for improvement.
https://github.com/llvm/llvm-project/issues/62651