There was a missing break, which led to an unannotated fallthrough when merging #112171. This has caused sanitizer builds to fail. This adds the missing break in the switch statement to ensure that the fallthrough does not occur.
As part of FEAT_PAuthLR, a new DWARF Frame Instruction was introduced, `DW_CFA_AARCH64_negate_ra_state_with_pc`. This instructs Libunwind that the PC has been used with the signing instruction. This change includes three commits - Libunwind support for the newly introduced DWARF Instruction - CodeGen Support for the DWARF Instructions - Reversing the changes made in #96377. Due to `DW_CFA_AARCH64_negate_ra_state_with_pc`'s requirements to be placed immediately after the signing instruction, this would mean the CFI Instruction location was not consistent with the generated location when not using FEAT_PAuthLR. The commit reverses the changes and makes the location consistent across the different branch protection options. While this does have a code size effect, this is a negligible one. For the ABI information, see here: https://github.com/ARM-software/abi-aa/blob/853286c7ab66048e4b819682ce17f567b77a0291/aadwarf64/aadwarf64.rst#id23
When printing a memory operand in MIR, this line https://github.com/llvm/llvm-project/blob/d37bc32a65651e647148236ffb9728ea2e77eac3/llvm/lib/CodeGen/MachineOperand.cpp#L1247 calls this https://github.com/llvm/llvm-project/blob/d37bc32a65651e647148236ffb9728ea2e77eac3/llvm/include/llvm/Support/Alignment.h#L238 which assumes `Rhs` (the size in this case) is positive. But Wasm reference types' size is set to 0: https://github.com/llvm/llvm-project/blob/d37bc32a65651e647148236ffb9728ea2e77eac3/llvm/include/llvm/CodeGen/ValueTypes.td#L326-L328 `getSize() > 0` condition was added with the Wasm reference types support in https://github.com/llvm/llvm-project/commit/46667a10039b664b953eb70534c27627b35a267d, and it looks it was removed in #84751. This revives the condition so that Wasm reference types will not crash the MIR printer.
If a dereferenceability fact is provided through `!dereferenceable` (or similar), it may only hold on the given control flow path. When we use `isSafeToSpeculativelyExecute()` to check multiple instructions, we might make use of `!dereferenceable` information that does not hold at the speculation target. This doesn't happen when speculating instructions one by one, because `!dereferenceable` will be dropped while speculating. Fix this by checking whether the instruction with `!dereferenceable` dominates the context instruction. If this is not the case, it means we are speculating, and cannot guarantee that it holds at the speculation target. Fixes https://github.com/llvm/llvm-project/issues/108854.
This is a follow-up to address a suggestion from https://github.com/llvm/llvm-project/pull/105619. The main goal of this change is to efficiently implement stable hash functions using the xxh3 64bits API. `stable_hash_combine_range` and `stable_hash_combine_array` functions are removed and consolidated into a more general `stable_hash_combine` function that takes an `ArrayRef<stable_hash>` as input.
Remove getSizeOrUnknown call when MachineMemOperand is created. For Scalable TypeSize, the MemoryType created becomes a scalable_vector. 2 MMOs that have scalable memory access can then use the updated BasicAA that understands scalable LocationSize. Original Patch by Harvin Iriawan Co-authored-by: David Green <david.green@arm.com>