Add more test cases for `s_bitreplicate` constant folding.

This patch disables parts of clang/test/Sema/code_align.c that need
__int128_t to be defined. This will fix failures on Arm v7 buildbots
due to #70762

Following bots are failing:
https://lab.llvm.org/buildbot/#/builders/245
https://lab.llvm.org/buildbot/#/builders/178
https://lab.llvm.org/buildbot/#/builders/182
https://lab.llvm.org/buildbot/#/builders/186
https://lab.llvm.org/buildbot/#/builders/187

The `createParallelComputeFunction` crashed when calling
`getFunctionTypeAttrName` during the creation of a new `FuncOp` inside
the pass. The problem is that `getFunctionTypeAttrName` looks up the
attribute name for the function type which in this case is `func.func`.
However, `name.getAttributeNames()` was empty when clients used
`llvm.func` instead of `func.func`.

To fix this, the `func` dialect is now registered as a dependent
dialect. Also, I've added an assertion which could save other people
some time.

Fixes #71281, fixes #64326.

-no-pie[1]/-nopie is rarely used and among the rare uses almost
everwhere uses -no-pie, since GCC does not recognize -nopie.
However, OpenBSD seems to use -nopie. Therefore, make -nopie specific
to OpenBSD to prevent newer ToolChains (Solaris, SerenityOS) from cargo
culting and copying -nopie.

[1]: https://reviews.llvm.org/D35462

This reverts commit ba359866.

The PR https://github.com/llvm/llvm-project/pull/70817 introduced a
small bug, the tests failed on ppc64-aix with:

```
RUN: at line 186: mkdir -pv /home/powerllvm/powerllvm_env/aix-ppc64/clang-ppc64-aix/build/tools/clang/test/Driver/Output/darwin-header-search-libcxx.cpp.tmp/install/bin
+ mkdir -pv /home/powerllvm/powerllvm_env/aix-ppc64/clang-ppc64-aix/build/tools/clang/test/Driver/Output/darwin-header-search-libcxx.cpp.tmp/install/bin
mkdir: illegal option -- v
Usage: mkdir [-p] [-e] [-m mode] Directory ... 
```

This PR removes the verbose flag from both `mkdir` and `ln -s`.

This patch added backend consumption on a new loop metadata:
!1 = !{!"llvm.loop.align", i32 64}
which is generated from clang's new loop attribute:
[[clang::code_align()]]
clang patch: #70762

foward -> forward

vmadd: (mul (add x, 1), y) -> (add (mul x, y), y)
           (mul x, add (y, 1)) -> (add x, (mul x, y))
    vnmsub: (mul (sub 1, x), y) -> (sub y, (mul x, y))
            (mul x, (sub 1, y)) -> (sub x, (mul x, y))
    
    Comparison with gcc:
    vmadd: https://gcc.godbolt.org/z/xjePx87Y7
    vnsub: https://gcc.godbolt.org/z/b17zG7nT1

HLFIR lowering as been set by default now and FIR lowering support will
be removed in the near future. This patch removes the specific FIR check
lines.

Add armeb support when incoming bc is arm big endian:
Fix error: could not infer e_machine from bitcode target triple
armebv7-linux-gnueabi.

Whenever LPStartEncoding was different from DW_EH_PE_omit, we used to
miscalculate LPStart. As a result, landing pads were assigned wrong
addresses. Fix that.

MLIR can't really be const-correct (it would need a `ConstValue` class
alongside the `Value` class really, like `ArrayRef` and
`MutableArrayRef`). This is however making is more consistent: method
that are directly modifying the Value shouldn't be marked const.

This patch adds the following semantic check:

```
The ancestor device-modifier must not appear on the device clause on any
directive other than the target construct.
```

When we record and replay kernels we should not error out early if there
is a chance the program might still run fine. This patch will:
1) Fallback to the allocation heuristic if the VAMap doesn't work.
2) Adjust the memory start to match the required address if possible.
3) Adjust the (guessed) pointer arguments if the memory start adjustment
   is impossible. This will allow kernels without indirect accesses to
   work while indirect accesses will most likely fail.

[mlir] Non-void lambda does not return a value in all control paths in yieldReplacementForFusedProducer (NFC)

/llvm-project/mlir/lib/Dialect/SCF/Transforms/TileUsingInterface.cpp:703:5: error: non-void lambda does not return a value in all
 control paths [-Werror,-Wreturn-type]
    };
    ^
1 error generated.

This patch is used to test whether fixupkind for bl can be returned
correctly. When BL has target-flags(loongarch-call), there is no error.
But without this flag, an assertion error will appear. So the test is
just tagged as "Expectedly Failed" now until the following patch fix it.

[Clang] Fix finding instantiated decls for class template specializations during instantiation (#72346)

This change aims to fix
https://github.com/llvm/llvm-project/issues/70375

It appears to me that the logic here should be handling specializations
in general, not just partial specialization. It also seems that both the
comment before the block and the `isInstantiationOf(ClassTemplate,
SpecTemplate)` below agree with my judgement.

The issue might just be a mistake that someone mistaken specialization
as a special case of partial specializations, while it's actually the
other way around.

Needs some experts to comment here if this is the right fix. 

The code that caused clang ICE is added as a test case.

In present-day debug-info, when you delete all instructions, you delete
all their debug-info with it because debug-info is stored in
instructions. With debug-info stored in DPValue objects however,
deleting instructions causes DPValue objects to clump together into a
large blob of debug-info that hangs around in the block, as nothing has
explicitly deleted it.

To restore this behaviour, scatter calls to dropDbgValues around in
places that used to delete chunks of dbg.values, for example during
stripDebugInfo and in the code that deletes everything after an
Unreachable instruction. DCE is another example.

The tests with --try... added to them are new scenarios where we can now
correctly replicate the "normal" debug-info behaviour. Alas, there's no
explicit test for the opt -strip-debug option though (in dbg.value mode
or DPValue mode).

Proof: https://alive2.llvm.org/ce/z/36FySK

Closes #66787.

This is nearly an NFC, the only change is potentially to order that
values are created/names.

Otherwise it is a slight speed boost/simplification to avoid having to
go through the `getFreelyInverted` recursive logic twice to simplify
the extra `not` op.

With the current logic of `if(isFreeToInvert(Op)) return Not(Op)` its
fairly easy to either 1) cause regressions or 2) infinite loops
if the folds we have for `Not(Op)` ever de-sync with the cases we
know are freely invertible.

This patch adds `getFreeInverted` which is able to build the free
inverted op along with check for free inversion to alleviate this
problem.

Some Instructions (select/min/max) are inverted by just inverting the
operands. So the answer of whether they are free to invert is really
just whether the operands are free to invert.

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

If `Y` and `Z` are constant then we can simplify to `(X - W) + (Y -
Z)`. If `Y == Z` we can fold to `X - W`.

Note these transform exist outside of InstCombine. The purpose of this
commit is primarily to make it so that folds can generate these
simplifiable patterns without having to worry about creating an inf
loop.

https://github.com/llvm/llvm-project/pull/69238 caused breakage in
VSCode debug console usage -- the user's input is always treated as
commands instead of expressions (the same behavior as if empty command
escape prefix is specified).

The bug is in one overload of `GetString()` which did not respect the
default value of "\`". But more important, I am puzzled to find out why
the regression is not caught by lldb test (testdap_evaluate). Turns out
https://github.com/llvm/llvm-project/pull/69238

 specifies
commandEscapePrefix default value in test framework to be "\`" while
VSCode will default not specify any commandEscapePrefix at all. Changing
it to None will fail `testdap_evaluate`. We should align the default
behavior between DAP client and testcase.

This patches fixes the bug in `GetString()` and changed the default
value of commandEscapePrefix in testcases to be None (be consistent with
IDE).

Co-authored-by: jeffreytan81 <jeffreytan@fb.com>

HLFIR lowering has been set by default now and FIR lowering support will
be removed in the near future. This patch is the first of a series to
update the OpenACC lowering tests to check only the HLFIR lowering and
remove and specific FIR check lines.

Summary:
We call the global constructors by function pointer. For whatever reason
the NVPTX architecture relies very specifically on the arguments to the
function pointer invocation matching what the function is implemented
as. This is problematic as most of these constructors are generated
with no arguments. This patch removes the extended arguments that GNU
and LLVM use for the constructors optionally so that it can support the
common case.

Reverts llvm/llvm-project#72611 for more follow-up discussions

Three existing test cases {get_icall_data_read_write, get_icall_data_read_write_with_weight,get_icall_data_read_write_big_endian} have common test data and testing
logic. Extract common code into `testICallDataReadWrite`.
- Add helper function `addValueProfData` and `testValueDataArray`. This two helper functions are used by `testICallDataReadWrite`, and possibly other test cases.

This test is the last holdout that still uses the legacy loop simplify
CFG pass. The issues originally pointed out in the test comments seem to
have been fixed now as there are no MemorySSA verification failures.