https://reviews.llvm.org/D84191 caused a html doc build issue with the changes in `llvm-objdump.rst`. It looks like a blank line is missing from the `code-block` directives.

Test Plan:

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

Reviewers: sebpop
Reviewed By: hiraditya

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

[X86] When manually creating intrinsic nodes in X86ISelLowering, make sure we use getTargetConstant and pointer type for the intrinsic ID.

Doesn't really matter in practice but that's how the nodes are
normally created by SelectionDAGBuilder. So we should match.

Found by temporarily hacking type checks into isel table.

This makes sure VPTERNLOG is generated with MVT::i8 immediate
as its SDNode declaration in X86InstrFragmentsSIMD.td declares.

This is used for DBPSADBW which has a i32 immediate for its
intrinsic and an i8 immediate in tablegen isel patterns.

This is the type declared in X86InstrFragmentsSIMD.td. ISel pattern
matching doesn't check so it doesn't matter in practice. Maybe for
SelectionDAG CSE it would matter.

Different training algorithms may produce models that, besides the main
policy output (i.e. inline/don't inline), produce additional outputs
that are necessary for the next training stage. To facilitate this, in
development mode, we require the training policy infrastructure produce
a description of the outputs that are interesting to it, in the form of
a JSON file. We special-case the first entry in the JSON file as the
inlining decision - we care about its value, so we can guide inlining
during training - but treat the rest as opaque data that we just copy
over to the training log.

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

When diffing disassembly dump of two binaries, I see lots of noises from mismatched jump target addresses and global data references, which unnecessarily causes diffs on every function, making it impractical. I'm trying to symbolize the raw binary addresses to minimize the diff noise.
In this change, a local branch target is modeled as a label and the branch target operand will simply be printed as a label. Local labels are collected by a separate pre-decoding pass beforehand. A global data memory operand will be printed as a global symbol instead of the raw data address. Unfortunately, due to the way the disassembler is set up and to be less intrusive, a global symbol is always printed as the last operand of a memory access instruction. This is less than ideal but is probably acceptable from checking code quality point of view since on most targets an instruction can have at most one memory operand.

So far only the X86 disassemblers are supported.

Test Plan:

llvm-objdump -d  --x86-asm-syntax=intel --no-show-raw-insn --no-leading-addr :
```
Disassembly of section .text:

<_start>:
               	push	rax
               	mov	dword ptr [rsp + 4], 0
               	mov	dword ptr [rsp], 0
               	mov	eax, dword ptr [rsp]
               	cmp	eax, dword ptr [rip + 4112]  # 202182 <g>
               	jge	0x20117e <_start+0x25>
               	call	0x201158 <foo>
               	inc	dword ptr [rsp]
               	jmp	0x201169 <_start+0x10>
               	xor	eax, eax
               	pop	rcx
               	ret
```

llvm-objdump -d  **--symbolize-operands** --x86-asm-syntax=intel --no-show-raw-insn --no-leading-addr :
```
Disassembly of section .text:

<_start>:
               	push	rax
               	mov	dword ptr [rsp + 4], 0
               	mov	dword ptr [rsp], 0
<L1>:
               	mov	eax, dword ptr [rsp]
               	cmp	eax, dword ptr  <g>
               	jge	 <L0>
               	call	 <foo>
               	inc	dword ptr [rsp]
               	jmp	 <L1>
<L0>:
               	xor	eax, eax
               	pop	rcx
               	ret
```

Note that the jump instructions like `jge 0x20117e <_start+0x25>` without this work is printed as a real target address and an offset from the leading symbol. With a change in the optimizer that adds/deletes an instruction, the address and offset may shift for targets placed after the instruction. This will be a problem when diffing the disassembly from two optimizers where there are unnecessary false positives due to such branch target address changes. With `--symbolize-operand`, a label is printed for a branch target instead to reduce the false positives. Similarly, the disassemble of PC-relative global variable references is also prone to instruction insertion/deletion.

Reviewed By: jhenderson, MaskRay

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

Modify case style of function names following clang-tidy.

Reviewed By: simoll

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

While the original implementation added in D85787 / ae7f0881
is not incorrect, it is known to be suboptimal.

In particular, it is not incorrect to use the basic block
in which the original `insertvalue` instruction is located
as the merge point, that is not necessarily optimal,
as `@test6` shows.

We should look at all the AggElts, and, if they are all defined
in the same basic block, then that is the basic block we should use.

On RawSpeed library, this catches +4% (+50) more cases.
On vanilla LLVM test-suits, this catches +12% (+92) more cases.

[NFC][InstCombine] PHI-aware aggregate reconstruction: don't capture UseBB in lambdas, take it as argument

In a following patch, UseBB will be detected later,
so capturing it is potentially error-prone (capture by ref vs by val).

Also, parametrized UseBB will likely be needed
for multiple levels of PHI indirections later on anyways.

This is NFC at the moment, because right now we always insert the PHI
into the same basic block in which the original `insertvalue` instruction
is, but that will change.

Also, fixes addition of the suffix to the value names.

Even without handling several layers of PHI nodes,
we can handle more cases, as `@test6` shows.

Remove `_dyld_find_unwind_sections` implementation for macOS that is
10.6 or previous. 10.6 is no longer supported for TOT libunwind after
removing its libkeymgr dependency.

Reviewed By: mstorsjo, pete, #libunwind

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

Add targets to emit SPIR-V targeted to Mesa's OpenCL support, using
SPIR-V 1.1.

Substantially based on Dave Airlie's earlier work.

libclc: spirv: remove step/smoothstep apis not defined for SPIR-V

libclc: disable inlines for SPIR-V builds

Reviewed By: jvesely, tstellar, jenatali

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

The SPIR spec states that all OpenCL built-in functions should be
overloadable and mangled, to ensure consistency.

Add the overload attribute to functions which were missing them:
work dimensions, memory barriers and fences, and events.

Reviewed By: tstellar, jenatali

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

Fix FP_ILOGBNAN definition to match the opencl-c-base.h one and
guarantee that FP_ILOGBNAN and FP_ILOGB0 are different. Doing that
implies fixing ilogb() implementation to return the right value.

Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>

Reviewed By: jvesely

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

Reviewed By: ftynse

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

Some of the lower implementations were relying on this, however the
type was not set depending on which form .lower* helper form you were
using. For instance, if you used an unconditonal lower(), the type was
never set. Most of the lower actions do not benefit from a type
parameter, and just expand in terms of the original operation's types.

However, some lowerings could benefit from an additional type hint to
combine a promotion and an expansion. An example of this is for
add/sub sat. The DAG integer legalization tries to use smarter
expansions directly when promoting the integer type, and doesn't
always produce the same instruction with a wider type.

Treat this as an optional hint argument, that only means something for
specific lower actions. It may be useful to generalize this mechanism
to pass a full list of type indexes and desired types, but I haven't
run into a case like that yet.

[AIX][XCOFF][Patch1] Provide decoding trace back table information API for xcoff object file for llvm-objdump -d

SUMMARY:

1. This patch provided API for decoding the traceback table info and unit test for the these API.

2. Another patchs will do the following things:
2.1 added a new option --traceback-table to decode the trace back table information for xcoff object file when
using llvm-objdump to disassemble the xcoff objfile.

2.2 print out the  traceback table information for llvm-objdump.

Reviewers:  Jason liu, Hubert Tong, James Henderson

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

LBAEL => LABEL

I encountered this typo elsewhere and I decided to run a global search.
It probably was unnoticed because I think CHECK-LBAEL: is ignored by
lit.

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

If we already found a killing def (= a def that completely overwrites
the location) that dominates an access, we can skip processing it
further.

This does not help with compile-time, but increases the number of memory
accesses we can process with the same scan budget, leading to more
stores being eliminated.

Improvements with this change

Same hash: 203 (filtered out)
Remaining: 34
Metric: dse.NumFastStores

Program                                        base    dom     diff
 test-suite...rolangs-C++/family/family.test     2.00    4.00  100.0%
 test-suite...ProxyApps-C++/CLAMR/CLAMR.test   172.00  229.00  33.1%
 test-suite...ks/Prolangs-C/agrep/agrep.test    10.00   12.00  20.0%
 test-suite...oxyApps-C++/miniFE/miniFE.test    44.00   51.00  15.9%
 test-suite...marks/7zip/7zip-benchmark.test   1285.00 1474.00 14.7%
 test-suite...006/450.soplex/450.soplex.test   254.00  289.00  13.8%
 test-suite...006/447.dealII/447.dealII.test   2466.00 2798.00 13.5%
 test-suite...000/197.parser/197.parser.test     9.00   10.00  11.1%
 test-suite.../Benchmarks/nbench/nbench.test    85.00   91.00   7.1%
 test-suite...ce/Applications/siod/siod.test    68.00   72.00   5.9%
 test-suite...ications/JM/lencod/lencod.test   786.00  824.00   4.8%
 test-suite...6/464.h264ref/464.h264ref.test   765.00  798.00   4.3%
 test-suite.../Benchmarks/Ptrdist/bc/bc.test   105.00  109.00   3.8%
 test-suite...lications/obsequi/Obsequi.test    29.00   28.00  -3.4%
 test-suite...3.xalancbmk/483.xalancbmk.test   1322.00 1367.00  3.4%
 test-suite...chmarks/MallocBench/gs/gs.test   118.00  122.00   3.4%
 test-suite...T2006/401.bzip2/401.bzip2.test    60.00   62.00   3.3%
 test-suite...6/482.sphinx3/482.sphinx3.test    30.00   31.00   3.3%
 test-suite...rks/tramp3d-v4/tramp3d-v4.test   862.00  887.00   2.9%
 test-suite...telecomm-gsm/telecomm-gsm.test    78.00   80.00   2.6%
 test-suite...ediabench/gsm/toast/toast.test    78.00   80.00   2.6%
 test-suite.../Applications/SPASS/SPASS.test   163.00  167.00   2.5%
 test-suite...lications/ClamAV/clamscan.test   240.00  245.00   2.1%
 test-suite...006/453.povray/453.povray.test   1392.00 1419.00  1.9%
 test-suite...000/255.vortex/255.vortex.test   211.00  215.00   1.9%
 test-suite...:: External/Povray/povray.test   1295.00 1317.00  1.7%
 test-suite...lications/sqlite3/sqlite3.test   175.00  177.00   1.1%
 test-suite...T2000/256.bzip2/256.bzip2.test    99.00  100.00   1.0%
 test-suite...0/253.perlbmk/253.perlbmk.test   629.00  635.00   1.0%
 test-suite.../CINT2006/403.gcc/403.gcc.test   1183.00 1194.00  0.9%
 test-suite.../CINT2000/176.gcc/176.gcc.test   647.00  653.00   0.9%
 test-suite...ications/JM/ldecod/ldecod.test   512.00  516.00   0.8%
 test-suite...0.perlbench/400.perlbench.test   1026.00 1034.00  0.8%
 test-suite...-typeset/consumer-typeset.test   1876.00 1877.00  0.1%
 Geomean difference                                             7.3%

This reverts commit a3036b38.

As requested in: https://reviews.llvm.org/D80833#2221866
Bug report: https://crbug.com/1117026