[all-commits] [llvm/llvm-project] efee57: Reland "[lit] Handle plain negations directly in t...

[Martin Storsjö via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: efee57925c3f46c74c6697234ce4f869e772834a
      https://github.com/llvm/llvm-project/commit/efee57925c3f46c74c6697234ce4f869e772834a
  Author: Martin Storsjö <martin at martin.st>
  Date:   2021-04-15 (Thu, 15 Apr 2021)

  Changed paths:
    M llvm/utils/lit/lit/TestRunner.py
    A llvm/utils/lit/tests/Inputs/shtest-not/exclamation-args-nested-none.txt
    A llvm/utils/lit/tests/Inputs/shtest-not/exclamation-args-none.txt
    A llvm/utils/lit/tests/Inputs/shtest-not/exclamation-calls-external.txt
    M llvm/utils/lit/tests/lit.cfg
    M llvm/utils/lit/tests/shtest-not.py

  Log Message:
  -----------
  Reland "[lit] Handle plain negations directly in the internal shell"

Keep running "not --crash" via the external "not" executable, but
for plain negations, and for cases that use the shell "!" operator,
just skip that argument and invert the return code.

The libcxx tests only use the shell operator "!" for negations,
never the "not" executable, because libcxx tests can be run without
having a fully built llvm tree available providing the "not"
executable.

This allows using the internal shell for libcxx tests.

It should be possible to reland this now that D99938 fixed the
one test failure in clang-tidy that broke when "not" was handled
internally, letting lit/python execute grep.exe directly instead
of via not.exe. (See D99330 and D99406 for more commentery on the
exact issue that broke and other potential ways of fixing it.)

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


  Commit: ee570e215353625a867fcbfd8c3089e9e0f8660d
      https://github.com/llvm/llvm-project/commit/ee570e215353625a867fcbfd8c3089e9e0f8660d
  Author: Martin Storsjö <martin at martin.st>
  Date:   2021-04-15 (Thu, 15 Apr 2021)

  Changed paths:
    M clang/test/CodeGen/ms_abi_aarch64.c

  Log Message:
  -----------
  [clang] [test] Share patterns in CodeGen/ms_abi_aarch64.c between cases. NFC.

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


  Commit: 5144f730a8a8a4c7c7984ff945187a9aa83c91ac
      https://github.com/llvm/llvm-project/commit/5144f730a8a8a4c7c7984ff945187a9aa83c91ac
  Author: Martin Storsjö <martin at martin.st>
  Date:   2021-04-15 (Thu, 15 Apr 2021)

  Changed paths:
    M llvm/lib/Target/AArch64/AArch64CallingConvention.td
    M llvm/lib/Target/AArch64/AArch64ISelLowering.cpp
    M llvm/lib/Target/AArch64/GISel/AArch64CallLowering.cpp
    M llvm/test/CodeGen/AArch64/GlobalISel/call-translator-tail-call.ll
    A llvm/test/CodeGen/AArch64/win64_vararg_float.ll

  Log Message:
  -----------
  [AArch64] Fix windows vararg functions with floats in the fixed args

On Windows, float arguments are normally passed in float registers
in the calling convention for regular functions. For variable
argument functions, floats are passed in integer registers. This
already was done correctly since many years.

However, the surprising bit was that floats among the fixed arguments
also are supposed to be passed in integer registers, contrary to regular
functions. (This also seems to be the behaviour on ARM though, both
on Windows, but also on e.g. hardfloat linux.)

In the calling convention, don't promote shorter floats to f64, but
convert them to integers of the same length. (Floats passed as part of
the actual variable arguments are promoted to double already on the
C/Clang level; the LLVM vararg calling convention doesn't do any
extra promotion of f32 to f64 - this matches how it works on X86 too.)

Technically, this is an ABI break compared to older LLVM versions,
but it fixes compatibility with the official platform ABI. (In practice,
floats among the fixed arguments in variable argument functions is
a pretty rare construct.)

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


Compare: https://github.com/llvm/llvm-project/compare/a1ed025d0ef9...5144f730a8a8