[all-commits] [llvm/llvm-project] 3a8f3b: [TSan] Handle FreeBSD specific indirection of libp...

Mon Feb 7 14:33:15 PST 2022

  Branch: refs/heads/release/14.x
  Home:   https://github.com/llvm/llvm-project
  Commit: 3a8f3b38760277fe1c32ac2d016185d7f5a96974
      https://github.com/llvm/llvm-project/commit/3a8f3b38760277fe1c32ac2d016185d7f5a96974
  Author: Dimitry Andric <dimitry at andric.com>
  Date:   2022-02-08 (Tue, 08 Feb 2022)

  Changed paths:
    M compiler-rt/lib/tsan/rtl/tsan_interceptors.h
    M compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp

  Log Message:
  -----------
  [TSan] Handle FreeBSD specific indirection of libpthread functions

Similar to 60cc1d3218fc for NetBSD, add aliases and interceptors for the
following pthread related functions:

- pthread_cond_init(3)
- pthread_cond_destroy(3)
- pthread_cond_signal(3)
- pthread_cond_broadcast(3)
- pthread_cond_wait(3)
- pthread_mutex_init(3)
- pthread_mutex_destroy(3)
- pthread_mutex_lock(3)
- pthread_mutex_trylock(3)
- pthread_mutex_unlock(3)
- pthread_rwlock_init(3)
- pthread_rwlock_destroy(3)
- pthread_rwlock_rdlock(3)
- pthread_rwlock_tryrdlock(3)
- pthread_rwlock_wrlock(3)
- pthread_rwlock_trywrlock(3)
- pthread_rwlock_unlock(3)
- pthread_once(3)
- pthread_sigmask(3)

In FreeBSD's libc, a number of internal aliases of the pthread functions
are invoked, typically with an additional prefixed underscore, e.g.
_pthread_cond_init() and so on.

ThreadSanitizer needs to intercept these aliases too, otherwise some
false positive reports about data races might be produced.

Reviewed By: dvyukov

Differential Revision: https://reviews.llvm.org/D119034

(cherry picked from commit 28fb22c90fe73877c529ddae74b9fe30a3a09234)

  Commit: 319f4b2d52e31b000db75a0a2484b5f2ab90534a
      https://github.com/llvm/llvm-project/commit/319f4b2d52e31b000db75a0a2484b5f2ab90534a
  Author: John Ericson <John.Ericson at Obsidian.Systems>
  Date:   2022-02-08 (Tue, 08 Feb 2022)

  Changed paths:
    M clang/CMakeLists.txt
    M lld/CMakeLists.txt

  Log Message:
  -----------
  [lld][clang][cmake] Clean up a few things

- If not using `llvm-config`, `LLVM_MAIN_SRC_DIR` now has a sane default

- `LLVM_CONFIG_PATH` will continue to work for LLD for back compat.

- More quoting of paths in an abundance of caution.

Reviewed By: nikic

Differential Revision: https://reviews.llvm.org/D118792

(cherry picked from commit e0eeae9a447004cc346d9bf36c0d02f45e276a7c)

  Commit: e6b508f49ae951b67ed99218003f9c966e59e2ae
      https://github.com/llvm/llvm-project/commit/e6b508f49ae951b67ed99218003f9c966e59e2ae
  Author: Sander de Smalen <sander.desmalen at arm.com>
  Date:   2022-02-08 (Tue, 08 Feb 2022)

  Changed paths:
    M llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
    M llvm/test/Transforms/LoopVectorize/AArch64/sve-epilog-vect.ll

  Log Message:
  -----------
  [LV] Use VScaleForTuning to allow wider epilogue VFs.

When the main loop is e.g. VF=vscale x 1 and the epilogue VF cannot
be any smaller, the vectorizer should try to estimate how many lanes are
executed at runtime and allow a suitable fixed-width VF to be chosen. It
can use VScaleForTuning to figure out what a suitable fixed-width VF could
be. For the case where the main loop VF is VF=vscale x 1, and VScaleForTuning=8,
it could still choose an epilogue VF upto VF=4.

This was a bit tricky to test, so this patch also introduces a wrapper
function to get 'VScaleForTuning' by also considering vscale_range.
If min and max are equal, then that will be the vscale we compile for.
It makes little sense to tune for a different width if the code
will not be portable for other widths.

Reviewed By: david-arm

Differential Revision: https://reviews.llvm.org/D118709

(cherry picked from commit eaee477edafed691dae206cea7c0a42893eb2821)

  Commit: ebe5b447270cc77ca8000d50d4032bc806658086
      https://github.com/llvm/llvm-project/commit/ebe5b447270cc77ca8000d50d4032bc806658086
  Author: Sanjay Patel <spatel at rotateright.com>
  Date:   2022-02-08 (Tue, 08 Feb 2022)

  Changed paths:
    M llvm/test/CodeGen/X86/sqrt-fastmath-tune.ll

  Log Message:
  -----------
  [x86] add test coverage for AMD Ryzen fast sqrt codegen; NFC

(cherry picked from commit 1eb4f88bfef1ab93b8286fdfd05a8b814507e329)

  Commit: 0f27bf28d255e2b227865aa0f5f6d63273eacefd
      https://github.com/llvm/llvm-project/commit/0f27bf28d255e2b227865aa0f5f6d63273eacefd
  Author: Sanjay Patel <spatel at rotateright.com>
  Date:   2022-02-08 (Tue, 08 Feb 2022)

  Changed paths:
    M llvm/lib/Target/X86/X86.td
    M llvm/test/CodeGen/X86/sqrt-fastmath-tune.ll

  Log Message:
  -----------
  [x86] enable fast sqrtss/sqrtps tuning for AMD Zen cores

As discussed in D118534, all of the recent AMD CPUs have
relatively fast (<14 cycle latency) "sqrtss" and "sqrtps"
instructions:
https://uops.info/table.html?search=sqrtps&cb_lat=on&cb_tp=on&cb_SNB=on&cb_SKL=on&cb_ZENp=on&cb_ZEN2=on&cb_ZEN3=on&cb_measurements=on&cb_avx=on&cb_sse=on

So we should set this tuning flag to alter codegen of plain
"sqrt(X)" expansion (as opposed to reciprocal-sqrt - there
is other test coverage for that pattern). The expansion is
both slower and less accurate than the hardware instruction.

Differential Revision: https://reviews.llvm.org/D119001

(cherry picked from commit fff3e1dbaa9ee2d91dc15b39defa88346f03a4c2)

  Commit: 2bae96d8a3490b1e5df19f4df56842448cb5caa7
      https://github.com/llvm/llvm-project/commit/2bae96d8a3490b1e5df19f4df56842448cb5caa7
  Author: Matt Devereau <matthew.devereau at arm.com>
  Date:   2022-02-08 (Tue, 08 Feb 2022)

  Changed paths:
    M llvm/lib/Target/AArch64/AArch64SVEInstrInfo.td
    M llvm/lib/Target/AArch64/SVEInstrFormats.td
    M llvm/test/CodeGen/AArch64/sve-fcvt.ll
    M llvm/test/CodeGen/AArch64/sve-fpext-load.ll
    M llvm/test/CodeGen/AArch64/sve-split-fcvt.ll

  Log Message:
  -----------
  [AArch64][SVE] Remove false register dependency for unary FP convert operations

Generate movprfx for floating point convert zeroing pseudo operations

Differential Revision: https://reviews.llvm.org/D118617

(cherry picked from commit 6b73a4cc7db96af1dd02db68c07fe4a807104c53)

Compare: https://github.com/llvm/llvm-project/compare/52557b918b1d...2bae96d8a349