1. [RISCV] Replace && with ||. Spotted by coverity. (details)
  2. [CostModel][X86] Improve AVX512 FDIV costs (details)
  3. [AArch64] Extra tests for vector shift. NFC (details)
  4. [ARM] MVE tests for vmull from a splat. NFC (details)
  5. [CostModel][X86] Add 512-bit bswap cost tests (details)
  6. [CostModel][X86] Add 512-bit bswap costs (details)
  7. [dfsan] Use the sanitizer allocator to reduce memory cost (details)
  8. [lld/mac] Use fewer magic numbers in magic $ld$ handling code (details)
Commit 8bde5f06a11d2ed30cc14b4960548d8da7a167b8 by craig.topper
[RISCV] Replace && with ||. Spotted by coverity.

We should be exiting when the shift amount is greater than
the bit width regardless of whether it is a power of 2.

Reported by Simon Pilgrim here

This requires getting a shift amount that is out of bounds that
wasn't already optimized by SelectionDAG. This would be pretty
trick to construct a test for.

Or it would require a non-power of 2 shift amount and a mask
that has runs of ones and zeros of the next lowest power of 2 from
that shift amount. I tried a little to produce a test for this,
but didn't get it to work.
The file was modifiedllvm/lib/Target/RISCV/RISCVISelLowering.cpp
Commit ae973380c5f6be77ce395022be40350942260be9 by llvm-dev
[CostModel][X86] Improve AVX512 FDIV costs

Add missing v16f32/v8f64 costs and adjust other costs as well based off the SkylakeServer model
The file was modifiedllvm/lib/Target/X86/X86TargetTransformInfo.cpp
The file was modifiedllvm/test/Transforms/PhaseOrdering/X86/vdiv.ll
The file was modifiedllvm/test/Analysis/CostModel/X86/arith-fp.ll
Commit 8f8273c54db930badd721a932e3e150f812bd5ca by
[AArch64] Extra tests for vector shift. NFC
The file was addedllvm/test/CodeGen/AArch64/neon-shift-neg.ll
Commit c85766f79b2e2ebdb2a33e3456936cec11b10dc5 by
[ARM] MVE tests for vmull from a splat. NFC
The file was addedllvm/test/CodeGen/Thumb2/mve-vmull-splat.ll
Commit ed3b3cfeb9ea7a80d30225a06a9851b84b5138a6 by llvm-dev
[CostModel][X86] Add 512-bit bswap cost tests
The file was modifiedllvm/test/Analysis/CostModel/X86/bswap-vec.ll
Commit 432eff22ab53820d1c74ad5f7b034a2db950b9fd by llvm-dev
[CostModel][X86] Add 512-bit bswap costs
The file was modifiedllvm/test/Analysis/CostModel/X86/bswap-vec.ll
The file was modifiedllvm/lib/Target/X86/X86TargetTransformInfo.cpp
Commit 2c82588dacac52ba8168214c6814ce22277d6e88 by jianzhouzh
[dfsan] Use the sanitizer allocator to reduce memory cost

dfsan does not use sanitizer allocator as others. In practice,
we let it use glibc's allocator since tcmalloc needs more work
to be working with dfsan well. With glibc, we observe large
memory leakage. This could relate to two things:

1) glibc allocator has limitation: for example, tcmalloc can reduce memory footprint 2x easily

2) glibc may call unmmap directly as an internal system call by using system call number. so DFSan has no way to release shadow spaces for those unmmap.

Using sanitizer allocator addresses the above issues
1) its memory management is close to tcmalloc

2) we can register callback when sanitizer allocator calls unmmap, so dfsan can release shadow spaces correctly.

Our experiment with internal server-based application proved that with the change, in a-few-day run, memory usage leakage is close to what tcmalloc does w/o dfsan.

This change mainly follows MSan's code.

1) define allocator callbacks at dfsan_allocator.h|cpp

2) mark allocator APIs to be discard

3) intercept allocator APIs

4) make dfsan_set_label consistent with MSan's SetShadow when setting 0 labels, define dfsan_release_meta_memory when unmap is called

5) add flags about whether zeroing memory after malloc/free. dfsan works at byte-level, so bit-level oparations can cause reading undefined shadow. See D96842. zeroing memory after malloc helps this. About zeroing after free, reading after free is definitely UB, but if user code does so, it is hard to debug an overtainting caused by this w/o running MSan. So we add the flag to help debugging.

This change will be split to small changes for review. Before that, a question is
"this code shares a lot of with MSan, for example, dfsan_allocator.* and dfsan_new_delete.*.
Does it make sense to unify the code at sanitizer_common? will that introduce some
maintenance issue?"

Reviewed By: morehouse

Differential Revision:
The file was modifiedcompiler-rt/test/dfsan/custom.cpp
The file was modifiedcompiler-rt/lib/dfsan/dfsan.cpp
The file was modifiedcompiler-rt/lib/dfsan/dfsan.h
The file was modifiedcompiler-rt/lib/dfsan/dfsan_interceptors.cpp
The file was addedcompiler-rt/lib/dfsan/dfsan_new_delete.cpp
The file was modifiedcompiler-rt/lib/dfsan/dfsan_custom.cpp
The file was modifiedcompiler-rt/lib/dfsan/done_abilist.txt
The file was addedcompiler-rt/test/dfsan/interceptors.c
The file was modifiedcompiler-rt/lib/dfsan/CMakeLists.txt
Commit e91043744346babdeb1e57e8f46e5a7c8a98fbfb by thakis
[lld/mac] Use fewer magic numbers in magic $ld$ handling code

Also simply a conditional and de-alias a variable.
Minor cleanups, no behavior change.

Differential Revision:
The file was modifiedlld/MachO/InputFiles.cpp