Second attempt. This also reverts 50633868.

* gmake is needed on FreeBSD
* pkg can install libxml2 on FreeBSD
* Make the swig note into an RST note box.

Second attempt.

TBAA builder assumed that all loads/stores are inside of functions and
hit an assertion once it found loads and stores inside of an
omp::ReductionDeclareOp.

For now just don't add TBAA tags to those loads and stores. They would
end up in a different TBAA tree to the host function after
OpenMPIRBuilder inlines them anyway so there isn't an easy way of making
this work.

This will be useful for OpenMP too.

I changed the definition slightly to use `fir::isa_ref_type` (which also
includes llvm pointers) because I think it reads better using the common
type helpers. There shouldn't be any llvm pointers in lowering so this
isn't a functional change.

Pattern should be sorted in priority order since the pattern evalutor
stops checking as soon as it finds a faster sequence.
so for a * b - c * d, we prefer to match the 2nd operands of sub,
which can be use msub to fold them.

Refer to https://www.slideshare.net/chimerawang/instruction-combine-in-llvm

Fix https://github.com/llvm/llvm-project/issues/84152

Similar to #84187, this enables the existing test we have for checking the
scheduling info of the pseudos matches the real instructions, and adjusts the
scheduling info in the NeoverseN2 model to make sure all cases were handled.

Add neon bici test for haddu and shadd, prerequisite for #76644

llvm-project/clang/lib/Sema/SemaChecking.cpp:19192:15:
error: unused variable 'Field1Parent' [-Werror,-Wunused-variable]
  const Type *Field1Parent = Field1->getParent()->getTypeForDecl();
              ^
llvm-project/clang/lib/Sema/SemaChecking.cpp:19193:15:
error: unused variable 'Field2Parent' [-Werror,-Wunused-variable]
  const Type *Field2Parent = Field2->getParent()->getTypeForDecl();
              ^
2 errors generated.

Fixes https://github.com/llvm/llvm-project/issues/83267

See
https://lab.llvm.org/buildbot/#/builders/245/builds/21611/steps/5/logs/FAIL__Clang__constant-builtins-2_c.

GCC complains if we pass -Werror=format-security without -Wformat.
Reported at https://github.com/llvm/llvm-project/pull/83779#issuecomment-1985246797

As noted in
https://github.com/llvm/llvm-project/pull/84035#discussion_r1516817755
only files under the CPP folder should be in the `cpp` namespace.

Fixes #63216

* Add a conversion from `arith.constant` to `emitc.constant`.
* Drop the translation for `arith.constant`s.

This patch adds repository checks to the release-binaries workflow jobs.
People were observing that the job was running on a schedule in their
forks. This only happens on old forks, but those probably exist in great
number given how prolific LLVM is. This is also good practice anyways,
on top of solving the direct problem of these jobs running with the cron
schedule on people's forks.

These functions should not be allowed if the file position is
indeterminate (they return the file position).
This condition is now checked, and tests are improved to check it.

This adds operations for the unary minus and the unary plus operator.

This PR introduces a step after instruction selection where instructions
can be traversed from the perspective of their validity from the
specification point of view. The PR adds also a way to correct
load/store when there is a type mismatch contradicting the specification
-- an additional bitcast is inserted to keep types consistent.
Correspondent test cases are added and existing test cases are
corrected.

This PR helps to successfully validate with the `spirv-val` tool
(https://github.com/KhronosGroup/SPIRV-Tools) some output that
previously led to validation errors and crashes of back translation from
SPIRV to LLVM IR from the side of SPIRV Translator project
(https://github.com/KhronosGroup/SPIRV-LLVM-Translator).

The added step of bringing instructions to required by the specification
type correspondence can be (should be and will be) extended beyond
load/store instructions to ensure validity rules of other SPIRV
instructions related to type inference.

This patch implements
[CWG2586](https://cplusplus.github.io/CWG/issues/2583.html) "Common
initial sequence should consider over-alignment". Note that alignment of
union members doesn't have to match, as layout compatibility of unions
is not defined in terms of common initial sequence
(http://eel.is/c++draft/class.mem.general#25).

Attempt 2. The first one was trying to call isa<> on an MI reference that was free'd.

This reverts commit ee24409c.

Fixes that
```
Pattern {
  let tuple = (attr<"3 : i34">);
  not tuple.0;
  erase _;
}
```
would crash the PDLL parser because it expected a native constraint
after `not`.

These checks have been broken since 6afe9721.
The check_cxx_compiler_flag macro only takes two arguments and passing
three to it ends up calling
`cmake_check_compiler_flag(CXX "${_FLAG}" ${_RESULT})` with ${_FLAG}
equal to `-Werror` and the result variable being the actually tested
compiler flag.

I noticed this because some of the flags that I know should be supported
were being flagged as not supported. `--debug-trycompile` shows the
following surprising line in the generated CMakeLists.txt:
`add_definitions([==[-D-Wempty-body]==] [==[-Werror]==])` which then
results in the following error while running the check:
```
FAILED: CMakeFiles/cmTC_72736.dir/src.cxx.o
tmp/upstream-llvm-readonly/bin/clang++   -nodefaultlibs -std=c++17 -fcolor-diagnostics   -D-Wempty-body -Werror -MD -MT CMakeFiles/cmTC_72736.dir/src.cxx.o -MF CMakeFiles/cmTC_72736.dir/src.cxx.o.d -o CMakeFiles/cmTC_72736.dir/src.cxx.o -c .../cmake-build-all-sanitizers/CMakeFiles/CMakeScratch/TryCompile-nyh3QR/src.cxx
In file included from <built-in>:450:
<command line>:1:9: error: macro name must be an identifier
    1 | #define -Wempty-body 1
      |         ^
   1 error generated.
```

It would be great if CMake could be a bit more helpful here so I've
filed https://gitlab.kitware.com/cmake/cmake/-/issues/25735.

See also https://reviews.llvm.org/D146920.

Reviewed By: nikic

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

I'm making some changes to `Environment::getResultObjectLocation()`,
with the
ultimate goal of eliminating `RecordValue` entirely, and I'd like to
make sure
I don't break this behavior (and I've realized we don't have a test for
it yet).

This is the constructor's job, and we want to be able to test that it
does this.

With the many pseudos used in SVE codegen it can be too easy to miss
instructions. This enables the existing test we have for checking the
scheduling info of the pseudos matches the real instructions, and
adjusts the scheduling info in the NeoverseV1 model to make sure all are
handled. In the cases I could I opted to use the same info as in the
NeoverseV2 model, to keep the differences smaller.

Older versions of clang do not have __builtin_complex, but they
may define `__GNUC__`.

Resubmitting this after previous revert with the following changes:

- Split table into table_rhs_idx and table_candidate_idx so that
  bisect.bisect_left can be used without the `key` argument, which
  was introduced in Python 3.10
- Remove a re.Pattern type annotation

Original commit message:

Prior to this change, running UTC on larger tests, especially tests
with unnamed IR values, often resulted in a spuriously large diff
because e.g. TMPnn variables in the CHECK lines were renumbered. This
change attempts to reduce the diff by keeping those variable names the
same.

There are cases in which this "drift" of variable names can end up being
more confusing. The old behavior can be re-enabled with the
--reset-variable-names command line argument.

The improvement may not be immediately apparent in the diff of this change.
The point is that the diff of stable_ir_values.ll against
stable_ir_values.ll.expected after this change is smaller.

Ideally, we'd also keep meta variables for "global" objects stable, e.g.
for attributes (#nn) and metadata (!nn). However, that would require a
much more substantial refactoring of how we generate check lines, so I
left it for future work.

This reverts commit fb02f9ac.

Looks like some Python version incompatibility, will investigate.

PR #75982 had been created before these tests were added, therefore
some test were not updated.

Prior to this change, running UTC on larger tests, especially tests
with unnamed IR values, often resulted in a spuriously large diff
because e.g. TMPnn variables in the CHECK lines were renumbered. This
change attempts to reduce the diff by keeping those variable names the
same.

There are cases in which this "drift" of variable names can end up being
more confusing. The old behavior can be re-enabled with the
--reset-variable-names command line argument.

The improvement may not be immediately apparent in the diff of this change.
The point is that the diff of stable_ir_values.ll against
stable_ir_values.ll.expected after this change is smaller.

Ideally, we'd also keep meta variables for "global" objects stable, e.g.
for attributes (#nn) and metadata (!nn). However, that would require a
much more substantial refactoring of how we generate check lines, so I
left it for future work.

The match argument isn't used.

The match argument is unused.

The test case demonstrates how meta variables are needlessly renamed,
making diffs harder to read.

llvm-project/clang/lib/Frontend/FrontendActions.cpp:213:10:
error: moving a local object in a return statement prevents copy elision [-Werror,-Wpessimizing-move]
  213 |   return std::move(Consumers);
      |          ^
/Users/jiefu/llvm-project/clang/lib/Frontend/FrontendActions.cpp:213:10: note: remove std::move call here
  213 |   return std::move(Consumers);
      |          ^~~~~~~~~~         ~
1 error generated.

Close https://github.com/llvm/llvm-project/issues/71034

See

https://discourse.llvm.org/t/rfc-c-20-modules-introduce-thin-bmi-and-decls-hash/74755

This patch introduces reduced BMI, which doesn't contain the definitions
of functions and variables if its definitions won't contribute to the
ABI.

Testing is a big part of the patch. We want to make sure the reduced BMI
contains the same behavior with the existing and relatively stable
fatBMI. This is pretty helpful for further reduction.

The user interfaces part it left to following patches to ease the
reviewing.