[all-commits] [llvm/llvm-project] dc30b0: [ELF] --emit-relocs: fix missing STT_SECTION when ...

Mon Apr 25 20:29:34 PDT 2022

  Branch: refs/heads/release/14.x
  Home:   https://github.com/llvm/llvm-project
  Commit: dc30b0d3320da810f402a3fd1f79720cfa8eb98d
      https://github.com/llvm/llvm-project/commit/dc30b0d3320da810f402a3fd1f79720cfa8eb98d
  Author: Fangrui Song <i at maskray.me>
  Date:   2022-04-25 (Mon, 25 Apr 2022)

  Changed paths:
    M lld/ELF/Writer.cpp
    A lld/test/ELF/emit-relocs-synthetic.s

  Log Message:
  -----------
  [ELF] --emit-relocs: fix missing STT_SECTION when the first input section is synthetic

addSectionSymbols suppresses the STT_SECTION symbol if the first input section
is non-SHF_MERGE synthetic. This is incorrect when the first input section is synthetic
while a non-synthetic input section exists:

* `.bss : { *(COMMON) *(.bss) }`
  (abc388ed3cf0ef7e617ebe243d3b0b32d29e69a5 regressed the case because
  COMMON symbols precede .bss in the absence of a linker script)
* Place a synthetic section in another section: `.data : { *(.got) *(.data) }`

For `%t/a1` in the new test emit-relocs-synthetic.s, ld.lld produces incorrect
relocations with symbol index 0.
```
0000000000000000 <_start>:
       0: 8b 05 33 00 00 00             movl    51(%rip), %eax          # 0x39 <bss>
                0000000000000002:  R_X86_64_PC32        *ABS*+0xd
       6: 8b 05 1c 00 00 00             movl    28(%rip), %eax          # 0x28 <common>
                0000000000000008:  R_X86_64_PC32        common-0x4
       c: 8b 05 06 00 00 00             movl    6(%rip), %eax           # 0x18
                000000000000000e:  R_X86_64_GOTPCRELX   *ABS*+0x4
```

Fix the issue by checking every input section.

Reviewed By: ikudrin

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

(cherry picked from commit 7370a489b1005e424b23bd0009af2365aef4db53)

  Commit: 50c6ba751fa2c3ae8854ba09229bda62b3617c55
      https://github.com/llvm/llvm-project/commit/50c6ba751fa2c3ae8854ba09229bda62b3617c55
  Author: Craig Topper <craig.topper at sifive.com>
  Date:   2022-04-25 (Mon, 25 Apr 2022)

  Changed paths:
    M llvm/lib/Target/RISCV/MCTargetDesc/RISCVMatInt.cpp
    M llvm/test/CodeGen/RISCV/imm.ll

  Log Message:
  -----------
  [RISCV] Only try LUI+SH*ADD+ADDI for int materialization if LUI+ADDI+SH*ADD failed.

There's an assert in LUI+SH*ADD+ADDI materialization that makes sure the
lower 12 bits aren't zero since that case should have been handled as
LUI+ADDI+SH*ADD. But nothing prevented the LUI+SH*ADD+ADDI checks from
running after the earlier code handled it.

The sequence would be the same length or longer so it wouldn't replace
the earlier sequence, but the assert happened before that was checked.

The vector holding the sequence also wasn't reset before the second
check so that guaranteed the sequence would never be found to be
shorter.

This patch fixes this by only trying the second expansion when the
earlier fails.

Fixes PR54812.

Reviewed By: benshi001

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

(cherry picked from commit 70046438d02ba1ec6bc2e2fc496b610cc1068b0f)

  Commit: 58d5fbe2c20bbd2499675c2d7a35dc157c767fec
      https://github.com/llvm/llvm-project/commit/58d5fbe2c20bbd2499675c2d7a35dc157c767fec
  Author: Alex Brachet <abrachet at google.com>
  Date:   2022-04-25 (Mon, 25 Apr 2022)

  Changed paths:
    A llvm/test/tools/llvm-mt/notify_update.test
    M llvm/tools/llvm-mt/Opts.td
    M llvm/tools/llvm-mt/llvm-mt.cpp

  Log Message:
  -----------
  [llvm-mt] Add support /notify_update

`/notify_update` is an undocumented feature used by CMake. From their usage, it looks like this feature just changes `mt`'s exit code if the output file was changed. See https://gitlab.kitware.com/cmake/cmake/-/blob/master/Source/cmcmd.cxx#L2300 this is also consistent with some testing I have done of the mt.exeshipped with Visual Studio. See also the comment at https://gitlab.kitware.com/cmake/cmake/-/blob/master/Source/cmcmd.cxx#L2440.

There might be a more performant way to implement this by first checking calling `llvm::sys::fs::file_size()` and if it is the same as the new output's size use `llvm::WritableMemoryBuffer` and fallback to `llvm::FileOutputBuffer` otherwise,  but these don't inherit from a common ancestor so any implementation doing this would be really ugly.

Fixes https://github.com/llvm/llvm-project/issues/54329

Reviewed By: phosek

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

(cherry picked from commit e970d2823cf2a666cb597bf06ff8e0d0b880d361)

  Commit: 21ce6cfd1d9357b54173d43e3d18960f487f6663
      https://github.com/llvm/llvm-project/commit/21ce6cfd1d9357b54173d43e3d18960f487f6663
  Author: Fraser Cormack <fraser at codeplay.com>
  Date:   2022-04-25 (Mon, 25 Apr 2022)

  Changed paths:
    M llvm/test/CodeGen/RISCV/rvv/fixed-vectors-int-buildvec.ll

  Log Message:
  -----------
  [RISCV] Add tests showing incorrect BUILD_VECTOR lowering

These tests both use vector constants misidentified as VID sequences.
Because the initial run of elements has a zero step, the elements are
skipped until such a step can be identified. The bug is that the skipped
elements are never validated, even though the computed step is
incompatible across the entire sequence.

A fix will follow in a subseqeuent patch.

Reviewed By: craig.topper

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

(cherry picked from commit 00537946aa29928894ba140687de1b6f9494e44d)

  Commit: 9efcce92b55bc87627b52dd1139fb9031e400b52
      https://github.com/llvm/llvm-project/commit/9efcce92b55bc87627b52dd1139fb9031e400b52
  Author: Fraser Cormack <fraser at codeplay.com>
  Date:   2022-04-25 (Mon, 25 Apr 2022)

  Changed paths:
    M llvm/lib/Target/RISCV/RISCVISelLowering.cpp
    M llvm/test/CodeGen/RISCV/rvv/fixed-vectors-int-buildvec.ll

  Log Message:
  -----------
  [RISCV] Fix lowering of BUILD_VECTORs as VID sequences

This patch fixes a bug when lowering BUILD_VECTOR via VID sequences.
After adding support for fractional steps in D106533, elements with zero
steps may be skipped if no step has yet been computed. This allowed
certain sequences to slip through the cracks, being identified as VID
sequences when in fact they are not.

The fix for this is to perform a second loop over the BUILD_VECTOR to
validate the entire sequence once the step has been computed. This isn't
the most efficient, but on balance the code is more readable and
maintainable than doing back-validation during the first loop.

Fixes the tests introduced in D123785.

Reviewed By: craig.topper

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

(cherry picked from commit c5cac48549ed254cd5ad5eef770ebfb22ccd9f64)

  Commit: e19be4195b8700ee48a84a50e65b1d4612b22cca
      https://github.com/llvm/llvm-project/commit/e19be4195b8700ee48a84a50e65b1d4612b22cca
  Author: Fraser Cormack <fraser at codeplay.com>
  Date:   2022-04-25 (Mon, 25 Apr 2022)

  Changed paths:
    M llvm/test/CodeGen/RISCV/rvv/fixed-vectors-int-buildvec.ll

  Log Message:
  -----------
  [RISCV] Add another test showing incorrect BUILD_VECTOR lowering

This test shows a (contrived) BUILD_VECTOR which is correctly identified
as a sequence of ((vid * -3) / 8) + 5. However, the issue is that using
shift-right for the divide is invalid as the step values are negative.

This patch just adds the test: the fix is added in D123796.

Reviewed By: craig.topper

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

(cherry picked from commit 627e21048a2c040d3e353cc4f0eb8f207b6ea61c)

  Commit: 1f4c7b2a9120357c2ee91bc407bf443734df54ec
      https://github.com/llvm/llvm-project/commit/1f4c7b2a9120357c2ee91bc407bf443734df54ec
  Author: Fraser Cormack <fraser at codeplay.com>
  Date:   2022-04-25 (Mon, 25 Apr 2022)

  Changed paths:
    M llvm/lib/Target/RISCV/RISCVISelLowering.cpp
    M llvm/test/CodeGen/RISCV/rvv/fixed-vectors-int-buildvec.ll

  Log Message:
  -----------
  [RISCV] Don't emit fractional VIDs with negative steps

We can't shift-right negative numbers to divide them, so avoid emitting
such sequences. Use negative numerators as a proxy for this situation, since
the indices are always non-negative.

An alternative strategy could be to add a compiler flag to emit division
instructions, which would at least allow us to test the VID sequence
matching itself.

Reviewed By: craig.topper

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

(cherry picked from commit 3e678cb77264907fbc2899c291ce23af308073ff)

Compare: https://github.com/llvm/llvm-project/compare/324127d8da95...1f4c7b2a9120