Allow the user to allocate space in a binary that could be used by BOLT
for allocating new sections. The reservation is specified by two special
symbols recognizable by BOLT: __bolt_reserved_{start,end}.

The reserved space will be useful for optimizing the Linux kernel where
we cannot allocate a new executable segment. However, the support is not
limited to kernel binaries as some user-space application may find it
useful too.

This enables multivalue and reference-types in `-mcpu=generic`           
configuration. These proposals have been standardized and supported in   
all major browsers for several years at this point:                      
https://github.com/WebAssembly/proposals/blob/main/finished-proposals.md 

Previously, the macro expansion to be explicit for the test cases had
unintentionally forced the tests to always run in little-endian mode.

This change restores the tests' endianness switch, and ensures that
the tests always run on both a little- and big-endian platform.

This adds a "hidden" alias kind that allows using LLD when symlinked as
`ld`; however, it does not install `ld` as a symlink. This is to allow
either using a mixed toolchain with both LLD and GNU ld, or a pure LLD
toolchain where LLD has been installed (or symlinked) to `ld` for
compatibility w/ older tools that expect `ld`.

that separates out language and version. To avoid reinventing the wheel
and introducing subtle incompatibilities, this API uses the table of
languages and versiond defined by the upcoming DWARF 6 standard
(https://dwarfstd.org/languages-v6.html). While the DWARF 6 spec is not
finialized, the list of languages is broadly considered stable.

The primary motivation for this is to allow the Swift language plugin to
switch between language dialects between, e.g., Swift 5.9 and 6.0 with
out introducing a ton of new language codes. On the main branch this
change is considered NFC.

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

This change cleans up the clang driver handling of umbrella options like
-ffast-math, -funsafe-math-optimizations, and -ffp-model, and aligns the
behavior of -ffp-model=fast with -ffast-math with regard to the linking
of crtfastmath.o.

We agreed in a previous review that the fast-math options should not
attempt to change the -fdenormal-fp-math option, which is inherently
target-specific.

The clang user's manual claims that -ffp-model=fast "behaves identically
to specifying both -ffast-math and -ffp-contract=fast." Since
-ffast-math causes crtfastmath.o to be linked if it is available, that should
also happen with -ffp-model=fast.

I am going to be proposing further changes to -ffp-model=fast,
decoupling it from -ffast-math and introducing a new
-ffp-model=aggressive that matches the current behavior, but I wanted
to solidfy the current behavior before I do that.

operator bool from NestedNameSpecifierLoc and
member function hasQualifier both do the same thing, returning true if
the private data member Qualifier is not nullptr, so clearly one of the
comments is wrong, and in this case it is the second one.

fixes https://github.com/llvm/llvm-project/issues/90472

Adjust #89280:

* ELFOSABI_LINUX is a historical alias that should not be used in new
  code. readelf -h displays "UNIX - GNU" instead of "Linux".
* "OS" is inappropriate. Some values are architecture-specific, e.g.
  ELFOSABI_ARM.
* Drop lowercase, which seems a job of the caller.

Add some unittests.

Pull Request: https://github.com/llvm/llvm-project/pull/90270

* Fix a leak
* Fix a maybe unused warning
* Fix incorrect cxx_status entry

Introduce just the option definitions and support for their existance at
a few different points in the frontend. This will be followed soon by
functionality that uses it.

Reviewers: bcardosolopes, jansvoboda11, AaronBallman, erichkeane, MaskRay

Reviewed By: erichkeane

Pull Request: https://github.com/llvm/llvm-project/pull/89030

Addresses issue #89805.
Assignment + comparison performed in conditional statement. Resolved by
parenthesizing comparison operation.

Fixes #89805.

---------

Signed-off-by: Troy-Butler <squintik@outlook.com>

This patch adds constexpr support for __builtin_shufflevector and
__builtin_convertvector.

NB: the changes went in under 2903df02 , this commit is just github PR bookkeepping.

In the context of determining whether a class counts as an "aggregate",
a constructor template counts as a user-provided constructor.

Fixes #86384

It's basically always a bug to discard a scoped_lock or a unique_lock.

Fixes #89388

Fixes a couple of style issues, such as:

- unused includes
- variable naming
- `else if` after `return`

Some tests were missing DoNotOptimize annotations.

llvm-clang-x86_64-expensive-checks-debian buildbot was previously failing.

Fixes: https://lab.llvm.org/buildbot/#/builders/16/builds/64701.

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>