Created using spr 1.3.4

Created using spr 1.3.4

[skip ci]

The conditional branch from the loop latch will be replaced by a
single branch controlling the loop, so there is no extra overhead from
scalarization. This improves the cost esimates in some cases.

Fragment matching relies on symbol names to identify and register split
function fragments. However, as split fragments are often local symbols,
name aliasing is possible. For such cases, use symbol table to resolve
ambiguities.

This requires the presence of FILE symbols in the input binary. As BOLT
requires non-stripped binary, this is a reasonable assumption. Note that
`strip -g` removes FILE symbols by default, but `--keep-file-symbols`
can be used to preserve them.

Depends on: https://github.com/llvm/llvm-project/pull/89861

Test Plan:
Updated X86/fragment-lite.s

`ValueRange` is more easy to be extended (e.g., for padded iterator).

This fixes a TODO in the code.

Skip CoroSplit and CoroCleanup in LTO pre-link pipeline so that
CoroElide can happen after callee coroutine is imported into caller's
module in ThinLTO.

On Windows, running unit tests by directly invoking `llvm-lit.py` (e.g.
`python3 llvm-lit.py clang/test/Unit`) may create a folder named `%SystemDrive%`
in the current working directory. This appears to happen because `lit.cfg.py` in 
`clang/test/Unit` does not propagate the `SystemDrive` environment variable.

We can think of this as two separate combines

(czero_eqz x, (setne y, 0)) -> (czero_eqz x, y)
and
(czero_eqz x, x) -> x

Similary the (czero_nez x, (seteq x, 0)) -> x combine can be broken into

(czero_nez x, (seteq y, 0)) -> (czero_eqz x, y)
and
(czero_eqz x, x) -> x

isel already does the (czero_eqz x, (setne y, 0)) -> (czero_eqz x, y)
and (czero_nez x, (seteq y, 0)) -> (czero_eqz x, y) combines, but doing
them early could expose other opportunities.

We don't have any instructions defined yet, but that we can still read the correct number of bytes when disassembling. This should better match GNU objdump behavior.

Having them dump is useful for ad-hoc debugging (context:
https://github.com/llvm/llvm-project/issues/90046)

This can be used for testing perf overhead of pseudo-probe.

This changes `GlobalOpt` to skip/look-through `threadlocal.address`
intrinsic where apropriate.

This fixes issue #73314

Andrii found an issue where the BTF line info may have empty source
which seems wrong. The program is a Meta internal bpf program. I can
reproduce with latest upstream compiler as well. Let the bpf program
built without this patch and then with the following veristat check
where veristat is a bpf verifier tool to do kernel verification for bpf
programs:

  $ veristat -vl2 yhs.bpf.o --log-size=150000000 >& log
  $ rg '^;' log | sort | uniq -c | sort -nr | head -n10
   4206 ; } else if (action->dry_run) { @ src_mitigations.h:57
   3907 ; if (now < start_allow_time) { @ ban.h:17
   3674 ;  @ src_mitigations.h:0
3223 ; if (action->vip_id != ALL_VIPS_ID && action->vip_id != vip_id) {
@ src_mitigations.h:85
1737 ; pkt_info->is_dry_run_drop = action->dry_run; @
src_mitigations.h:26
   1737 ; if (mitigation == ALLOW) { @ src_mitigations.h:28
1737 ; enum match_action mitigation = action->action; @
src_mitigations.h:25
1727 ; void* res = bpf_map_lookup_elem(bpf_map, key); @
filter_helpers.h:498
1691 ; bpf_map_lookup_elem(&rate_limit_config_map, rule_id); @
rate_limit.h:76
   1688 ; if (throttle_cfg) { @ rate_limit.h:85

You can see

   3674 ;  @ src_mitigations.h:0

where we do not have proper line information and line number.

In LLVM Machine IR, some instructions may carry DebugLoc information
to specify where the corresponding source is for this instruction.
The information includes file_name, line_num and col_num.
Each instruction may also attribute to a function in debuginfo.
So there are two ways to find file_name for a particular insn:
  (1) find the corresponding function in debuginfo
      (MI->getMF()->getFunction().getSubprogram()) and then
      find the file_name from DISubprogram.
  (2) find the corresponding file_name from DebugLoc.

The option (1) is used in current implementation. This mostly works.
But if one instruction is somehow generated from multiple functions,
the compiler has to pick just one. This may cause a mismatch between
file_name and line_num/col_num.

Besides potential incorrect mismatch of file_name vs. line_num/col_num,
There is another issue where some DebugLoc has line number 0. For
example,
I dumped the dwarf line table for the above bpf program:
    
Address Line Column File ISA Discriminator OpIndex Flags
------------------ ------ ------ ------ --- ------------- -------
-------------
0x0000000000000000 96 0 17 0 0 0 is_stmt
0x0000000000000010 100 12 17 0 0 0 is_stmt prologue_end
      0x0000000000000020      0     12     17   0             0       0
0x0000000000000058 37 7 17 0 0 0 is_stmt
      0x0000000000000060      0      0     17   0             0       0
      0x0000000000000088     37      7     17   0             0       0
0x0000000000000090 42 75 17 0 0 0 is_stmt
      0x00000000000000a8     42     52     17   0             0       0
0x00000000000000c0 120 9 17 0 0 0 is_stmt
      0x00000000000000c8      0      9     17   0             0       0
0x00000000000000d0 106 21 17 0 0 0 is_stmt
      0x00000000000000d8    106      3     17   0             0       0
0x00000000000000e0 110 25 17 0 0 0 is_stmt
      0x00000000000000f8    110     36     17   0             0       0
      0x0000000000000100      0     36     17   0             0       0
      ...
    
These DebugLoc with line number 0 needs to be skipped since we cannot
map them to the correct source code. Note that selftest
offset-reloc-basic.ll
has this issue as well which is adjusted by this patch.

With the above two fixes, empty lines for source annotation are removed.

  $ veristat -vl2 yhs.bpf.o --log-size=150000000 >& log
  $ rg '^;' log.latest | sort | uniq -c | sort -nr | head -n10
   4206 ; } else if (action->dry_run) { @ src_mitigations.h:57
   3907 ; if (now < start_allow_time) { @ ban.h:17
3223 ; if (action->vip_id != ALL_VIPS_ID && action->vip_id != vip_id) {
@ src_mitigations.h:85
1737 ; pkt_info->is_dry_run_drop = action->dry_run; @
src_mitigations.h:26
   1737 ; if (mitigation == ALLOW) { @ src_mitigations.h:28
1737 ; enum match_action mitigation = action->action; @
src_mitigations.h:25
1727 ; void* res = bpf_map_lookup_elem(bpf_map, key); @
filter_helpers.h:498
1691 ; bpf_map_lookup_elem(&rate_limit_config_map, rule_id); @
rate_limit.h:76
   1688 ; if (throttle_cfg) { @ rate_limit.h:85
   1670 ; if (rl_cfg) { @ rate_limit.h:77

You can see that we do not have empty line any more.

3223 ; if (action->vip_id != ALL_VIPS_ID && action->vip_id != vip_id) {
@ src_mitigations.h:85

Signed-off-by: Yonghong Song <yonghong.song@linux.dev>

Summary:
Previously we would build all of the plugins by default and then only
load some using the `LIBOMPTARGET_PLUGINS_TO_LOAD` variable. This patch
renamed this to `LIBOMPTARGET_PLUGINS_TO_BUILD` and changes whether or
not it will include the plugin in CMake.

Additionally this patch creates a new `Targets.def` file that allows us
to enumerate all of the enabled plugins. This is somewhat different from
the old method, and it's done this way for future use that will need to
be shared. This follows the same method that LLVM uses for its targets,
however it does require adding an extra include path.

Depends on https://github.com/llvm/llvm-project/pull/86868

A Darwin extension '%P' combined with an Objective-C pointer seems to
always be a bug.

'%P' will dump bytes at the pointed-to address (in contrast to '%p'
which dumps the pointer itself). This extension is only allowed in "OS
Log" contexts and is intended to be used like `%{uuid_t}.*16P` or
`%{timeval}.*P`. If an ObjC pointer is used, then the internal runtime
structure (aka, the is-a pointer and other runtime metadata) will be
dumped, which (IMO) is never the expectation.

A simple diagnostic can help flag these scenarios.

Resolves https://github.com/llvm/llvm-project/issues/89968



Co-authored-by: Jared Grubb <jgrubb@apple.com>

commit 8d41d93e3fceb3f3af77266f5a8388fc585150a5
Author: Pol Marcet Sardà <polmarcetsarda@gmail.com>
Date:   Sat Apr 20 12:19:49 2024 +0200

    Address some misc comments; added a diagnostic and expanded macros in
    testing.

commit 9493c0f290b558947d8b3ae8e1adf909b0fb9dcd
Author: Pol Marcet Sardà <polmarcetsarda@gmail.com>
Date:   Sun Mar 31 18:18:45 2024 +0200

    Following the review of sethp, I have made the following changes:

    -- Added diagnostic for the undefined shuffle of -1
    -- Validated support for _BitInt
    -- A bunch of other minnor tweaks here and there

commit 8273abc8d56ef8225cf4dba84f66a1e54a2ef036
Author: Pol Marcet Sardà <polmarcetsarda@gmail.com>
Date:   Thu Jan 4 12:31:08 2024 +0100

    Fix typo in file name

commit ff68f23921966c7d9605f91a47d6b481bf1d7a7b
Author: Pol Marcet Sardà <polmarcetsarda@gmail.com>
Date:   Thu Jan 4 11:26:08 2024 +0100

    Address suggestions from RKSimon

commit c14783de45687c754253c0cbf8a7834c7f986d80
Author: Pol Marcet Sardà <polmarcetsarda@gmail.com>
Date:   Sat Dec 30 13:59:00 2023 +0100

    [clang] Constexpr for __builtin_shufflevector and __builtin_convertvector

    Summary:

    This patch adds constexpr support for __builtin_shufflevector
    and __builtin_convertvector.

    A small oddity encountered was that the arg to the intrinsics may be an
    lvalue without any sort of implicit cast of any kind. I solved this
    through the EvaluateVectorOrLValue function, which treats the lvalue as
    if it was in an rvalue cast, which gets me the desired vector.

Co-Authored-By: Seth Pellegrino <seth@codecopse.net>

Normally, operator< accepting DataRefImpl is used when comparing
SymbolRef/ELFSymbolRef. However, it uses std::memcmp which interprets
DataRefImpl union as char string so that the result depends on host
endianness.
For ELFSymbolRef a specialized operator< can be used instead to produce
consistent ordering regardless of endianness by comparing the symbol
table index and symbol index fields separately.

Support patterns like

  Pat<(p0 frameindex:$fi), (ADD tframeindex:$fi, 0)>;

in the GlobalISel emitter in TableGen. Currently, using such a pattern
results in an error message.

Previously you got:
clang: error: invalid arch name 'rv64v', first letter should be 'e', 'i'
or 'g'

Which to me, unfamiliar with riscv, reads as if I should have used
"[eig]rv64v". Which is not what clang means.

Include the first bit in the error message to make this clearer:
clang: error: invalid arch name 'rv64v', first letter after 'rv64'
should be 'e', 'i' or 'g'

Apparently, nvcc does not compile for device the routines whose
definitions
are not marked with device attribute (note that the forward declarations
are already marked). It looks like it is different for class members,
i.e. marking just the declarations is enough.

After #84384, `Qualifiers::Mask` becomes 64-bit. So, operations like
`Mask &= ~U32` where `U32` is `unsigned` produce undesirable results
since higher 32 bits of `Mask` become zeroed while they should be
preserved. Fix that by explicitly casting `unsigned` values to
`uint64_t` in such operations. Signatures of fixed functions are
intentionally left intact instead of changing the argument itself to
`uint64_t` to keep things consistent with other functions working with
the same qualifiers and to emphasize that 64-bit masks should not be
used for these types of qualifiers.

This reverts the revert commit 6844c2fe, which was comprised
of the following commits:

1. f3f6f22d - [mlir-lsp] Initialize `Reply::method` member (#89857)
2. 37e13d49 - [mlir-lsp] Log invalid notification params (#89856)
3. ba1b52e6 - [mlir-lsp] Add `outgoingNotification` unit test
4. 84bc21f9 - [mlir-lsp] Add transport unit tests (#89855)

Of these, (4) specifically caused issues in Windows pre-merge buildbots,
in the `TransportTest.MethodNotFound` unit test that it added. The
failure was caused by a statement that asserted that opening a file
stream on a newly created temporary file did not result in an error, but
this assert failed on Windows.

This patch adds additional error logging for failures, to make it
clearer what went wrong when failures occur. This patch also addresses
the Windows failure by ensuring temporary files are created in the
system temporary directory.

This might help keep the test valid if vplan is removing dead intructions.

This speeds up the test.

Currently, a lot of `__builtin_reduce_*` function do not support
scalable vectors, i.e., ARM SVE and RISCV V. This PR adds support for
them. The main code change is to use a different path to extract the
type from the vectors, the rest is the same and LLVM supports the reduce
functions for `vscale` vectors.

This PR adds scalable vector support for:
- `__builtin_reduce_add`
- `__builtin_reduce_mul`
- `__builtin_reduce_xor`
- `__builtin_reduce_or`
- `__builtin_reduce_and`
- `__builtin_reduce_min`
- `__builtin_reduce_max`

Note: For all except `min/max`, the element type must still be an
integer value. Adding floating point support for `add` and `mul` is
still an open TODO.

Adding `erf` as unary and `powf` as binary.

Same as `max(arg, 0.0)` for `ReLU`, `powf(arg, const)` can be either a
generic (with broadcast) or a pair (`linalg.broadcast + linalg.powf`)
and then lowered "correctly". Either way, the lower dialects need to
know what kind of broadcast anyway, so no materialization of the
constant tensors should remain.

I want to flush the easy ones before we start working on type cast &
softmax.

Merge the non-record code paths into visitInitList().