SuccessChanges

Summary

  1. [llvm-readelf] Fix emitting incorrect number of spaces in '--hex-dump'. (details)
  2. Don't form a 'context-independent expr' reference to a member during (details)
  3. Supplement instr profile with sample profile. (details)
  4. [X86] Properly encode a 32-bit address with an index register and no base register in 16-bit mode. (details)
  5. [X86] Add support for {disp32} to control size of jmp and jcc instructions in the assembler (details)
  6. [X86] Detect if EFLAGs is live across XBEGIN pseudo instruction. Add it as livein to the basic blocks created when expanding the pseudo (details)
  7. [clang-tidy] Suppress one unittest on macOS. (details)
  8. [mlir][NFC] Polish copy removal transform (details)
  9. [GVN] Rewrite IsValueFullyAvailableInBlock(): no recursion, less false-negatives (details)
  10. [PowerPC] test case for adding dq form to isLegalAddressingMode, nfc (details)
  11. [clang][cmake] Force CMAKE_LINKER for multistage build in case of BOOTSTRAP_LLVM_ENABLE_LLD and MSVC (details)
  12. [llvm-readelf] - Do not treat SHT_ANDROID_RELR sections the same as SHT_RELR. (details)
Commit 6bf989b9474ace6a35021e6123d13b7fd59bf9f4 by Xing
[llvm-readelf] Fix emitting incorrect number of spaces in '--hex-dump'.

This patch helps teach llvm-readelf to emit a correct number spaces when
dumping in hex format.

Before this patch, when the hex data doesn't fill the 4th column, some
spaces are missing.

```
Hex dump of section '.sec':
0x00000000 00000000 00000000 00000000 00000000 ................
0x00000010 00000000 00000000 00000000 0000 ..............
```

After this patch:

```
Hex dump of section '.sec':
0x00000000 00000000 00000000 00000000 00000000 ................
0x00000010 00000000 00000000 00000000 0000     ..............
```

Reviewed By: grimar

Differential Revision: https://reviews.llvm.org/D84640
The file was modifiedllvm/tools/llvm-readobj/ObjDumper.cpp
The file was modifiedllvm/test/tools/llvm-readobj/ELF/hex-dump.test
Commit 23d6525cbdc9de7cbfe7640d1e9e4f25a0c5dd85 by richard
Don't form a 'context-independent expr' reference to a member during
name annotation.

Instead, defer forming the member access expression or DeclRefExpr until
we build the use of ClassifyName's result. Just build an
UnresolvedLookupExpr to track the LookupResult until we're ready to
consume it.

This also reverts commit 2f7269b6773de2750f9cd1417ef5f21cd6cf7a91 (other
than its testcase). That change was an attempted workaround for the same
problem.
The file was modifiedclang/lib/Parse/ParseExpr.cpp
The file was modifiedclang/include/clang/Sema/Sema.h
The file was modifiedclang/lib/Parse/ParseTentative.cpp
The file was modifiedclang/test/SemaTemplate/member-access-expr.cpp
The file was modifiedclang/lib/Parse/ParseDecl.cpp
The file was modifiedclang/lib/Sema/SemaExprMember.cpp
The file was modifiedclang/lib/Sema/SemaDecl.cpp
The file was modifiedclang/include/clang/Basic/TokenKinds.def
The file was modifiedclang/lib/Parse/Parser.cpp
Commit a23f62343cb79a3306fa64545db1d61c2d76b9ca by wmi
Supplement instr profile with sample profile.

PGO profile is usually more precise than sample profile. However, PGO profile
needs to be collected from loadtest and loadtest may not be representative
enough to the production workload. Sample profile collected from production
can be used as a supplement -- for functions cold in loadtest but warm/hot
in production, we can scale up the related function in PGO profile if the
function is warm or hot in sample profile.

The implementation contains changes in compiler side and llvm-profdata side.
Given an instr profile and a sample profile, for a function cold in PGO
profile but warm/hot in sample profile, llvm-profdata will either mark
all the counters in the profile to be -1 or scale up the max count in the
function to be above hot threshold, depending on the zero counter ratio in
the profile. The assumption is if there are too many counters being zero
in the function profile, the profile is more likely to cause harm than good,
then llvm-profdata will mark all the counters to be -1 indicating the
function is hot but the profile is unaccountable. In compiler side, if a
function profile with all -1 counters is seen, the function entry count will
be set to be above hot threshold but its internal profile will be dropped.

In the long run, it may be useful to let compiler support using PGO profile
and sample profile at the same time, but that requires more careful design
and more substantial changes to make two profiles work seamlessly. The patch
here serves as a simple intermediate solution.

Differential Revision: https://reviews.llvm.org/D81981
The file was addedllvm/test/Transforms/PGOProfile/suppl-profile.ll
The file was addedllvm/test/tools/llvm-profdata/Inputs/mix_sample.proftext
The file was modifiedllvm/lib/ProfileData/InstrProfWriter.cpp
The file was addedllvm/test/Transforms/PGOProfile/Inputs/suppl-profile.proftext
The file was modifiedllvm/lib/Transforms/Instrumentation/PGOInstrumentation.cpp
The file was modifiedllvm/docs/CommandGuide/llvm-profdata.rst
The file was modifiedllvm/lib/ProfileData/ProfileSummaryBuilder.cpp
The file was addedllvm/test/tools/llvm-profdata/suppl-instr-with-sample.test
The file was addedllvm/test/tools/llvm-profdata/Inputs/mix_instr.proftext
The file was modifiedllvm/tools/llvm-profdata/llvm-profdata.cpp
The file was modifiedllvm/lib/ProfileData/InstrProf.cpp
The file was modifiedllvm/include/llvm/ProfileData/InstrProf.h
The file was modifiedllvm/test/tools/llvm-profdata/overflow-instr.test
The file was addedllvm/test/Transforms/PGOProfile/Inputs/sample-profile.proftext
The file was modifiedllvm/include/llvm/ProfileData/InstrProfWriter.h
Commit a0ebac52df6d890fcba52e7db9ac66d0fc7c2582 by craig.topper
[X86] Properly encode a 32-bit address with an index register and no base register in 16-bit mode.

In 16-bit mode we can encode a 32-bit address using 0x67 prefix.
We were failing to do this when the index register was a 32-bit
register, the base register was not present, and the displacement
fit in 16-bits.

Fixes PR46866.
The file was modifiedllvm/test/MC/X86/code16gcc.s
The file was modifiedllvm/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp
Commit 25f193fb46dbdcc178946765aa929535199e2a4b by craig.topper
[X86] Add support for {disp32} to control size of jmp and jcc instructions in the assembler

By default we pick a 1 byte displacement and let relaxation enlarge it if necessary. The GNU assembler supports a pseudo prefix to basically pre-relax the instruction the larger size.

I plan to add {disp8} and {disp32} support for memory operands in another patch which is why I've included the parsing code and enum for {disp8} pseudo prefix as well.

Reviewed By: echristo

Differential Revision: https://reviews.llvm.org/D84709
The file was modifiedllvm/test/MC/X86/x86-32.s
The file was modifiedllvm/lib/Target/X86/AsmParser/X86AsmParser.cpp
The file was modifiedllvm/test/MC/X86/x86-16.s
Commit 647e861e080382593648b234668ad2f5a376ac5e by craig.topper
[X86] Detect if EFLAGs is live across XBEGIN pseudo instruction. Add it as livein to the basic blocks created when expanding the pseudo

XBEGIN causes several based blocks to be inserted. If flags are live across it we need to make eflags live in the new basic blocks to avoid machine verifier errors.

Fixes PR46827

Reviewed By: ivanbaev

Differential Revision: https://reviews.llvm.org/D84479
The file was modifiedllvm/lib/Target/X86/X86ISelLowering.cpp
The file was addedllvm/test/CodeGen/X86/pr46827.ll
Commit 8c9241a051fd677cfbfd9c79c6af9d714be7c792 by Artem Dergachev
[clang-tidy] Suppress one unittest on macOS.

Possibly a linker bug but I'm in a hurry to fix a buildbot.

Differential Revision: https://reviews.llvm.org/D84453
The file was modifiedclang-tools-extra/unittests/clang-tidy/ClangTidyDiagnosticConsumerTest.cpp
The file was modifiedclang-tools-extra/unittests/clang-tidy/ClangTidyOptionsTest.cpp
Commit 486d2750c7151d3d93b785a4669e2d7d5c9286ac by ehsan.nadjaran_toosi
[mlir][NFC] Polish copy removal transform

Address a few remaining comments in copy removal transform.

Differential Revision: https://reviews.llvm.org/D84529
The file was modifiedmlir/lib/Transforms/CopyRemoval.cpp
Commit e40315d2b4ed1e38962a8f33ff151693ed4ada63 by lebedev.ri
[GVN] Rewrite IsValueFullyAvailableInBlock(): no recursion, less false-negatives

While this doesn't appear to help with the perf issue being exposed by
D84108, the function as-is is very weird, convoluted, and what's worse,
recursive.

There was no need for `SpeculativelyAvaliableAndUsedForSpeculation`,
tri-state choice is enough. We don't even ever check for that state.

The basic idea here is that we need to perform a depth-first traversal
of the predecessors of the basic block in question, either finding a
preexisting state for the block in a map, or inserting a "placeholder"
`SpeculativelyAvaliable`,

If we encounter an `Unavaliable` block, then we need to give up search,
and back-propagate the `Unavaliable` state to the each successor of
said block, more specifically to the each `SpeculativelyAvaliable`
we've just created.

However, if we have traversed entirety of the predecessors and have not
encountered an `Unavaliable` block, then it must mean the value is fully
available. We could update each inserted `SpeculativelyAvaliable` into
a `Avaliable`, but we don't need to, as assertion excersizes,
because we can assume that if we see an `SpeculativelyAvaliable` entry,
it is actually `Avaliable`, because during the time we've produced it,
if we would have found that it has an `Unavaliable` predecessor,
we would have updated it's successors, including this block,
into `Unavaliable`

Reviewed By: fhahn

Differential Revision: https://reviews.llvm.org/D84181
The file was modifiedllvm/test/Transforms/GVN/loadpre-missed-opportunity.ll
The file was modifiedllvm/lib/Transforms/Scalar/GVN.cpp
Commit c2abdec722f119ebda0cee330fe8dd7bf9c6d506 by czhengsz
[PowerPC] test case for adding dq form to isLegalAddressingMode, nfc
The file was addedllvm/test/CodeGen/PowerPC/prefer-dqform.ll
Commit ad4ab81dccaa72d9b5137433a0923d325ff76135 by kbessonova
[clang][cmake] Force CMAKE_LINKER for multistage build in case of BOOTSTRAP_LLVM_ENABLE_LLD and MSVC

The issue with LLVM_ENABLE_LLD is that it just passes -fuse-ld=lld
to compiler/linker options which makes sense only for those platforms
where cmake invokes a compiler driver for linking. On Windows (MSVC) cmake
invokes the linker directly and requires CMAKE_LINKER to be specified
otherwise it defaults CMAKE_LINKER to be link.exe.

This patch allows BOOTSTRAP_LLVM_ENABLE_LLD to set CMAKE_LINKER in two cases:
* if building for host Windows,
* if crosscompiling for target Windows.

It also skips adding '-fuse-ld=lld' to make lld-link not warning
about 'unknown argument'.

This fixes build with `clang/cmake/caches/DistributionExample.cmake`
on Windows.

Reviewed By: phosek

Differential Revision: https://reviews.llvm.org/D80873
The file was modifiedclang/CMakeLists.txt
The file was modifiedllvm/cmake/modules/HandleLLVMOptions.cmake
Commit ee068aafbc5c6722158d5113290a211503e1cfe4 by grimar
[llvm-readelf] - Do not treat SHT_ANDROID_RELR sections the same as SHT_RELR.

Currently, when dumping section headers, llvm-readelf
prints "RELR" for SHT_ANDROID_RELR/SHT_RELR sections.
The behavior was introduced in D47919 and revealed in D84330.

But "SHT_ANDROID_RELR" has a different value from "SHT_RELR".
Also, "SHT_ANDROID_REL/SHT_ANDROID_RELA" are printed as "ANDROID_REL/ANDROID_RELA",
what makes the handling of the "SHT_ANDROID_RELR" inconsistent.

This patch makes llvm-readelf to print "ANDROID_RELR" instead of "RELR".

Differential revision: https://reviews.llvm.org/D84393
The file was modifiedllvm/test/tools/llvm-readobj/ELF/section-types.test
The file was modifiedllvm/tools/llvm-readobj/ELFDumper.cpp