This appears to have caused a variety of breakages, see comments on the PR.
> Summary:
> There are a few default options that LLVM adds that can be problematic
> for runtimes builds. These options are generally intended to handle
> building LLVM itself, but are also added when building in a runtimes
> mode. One such issue I've run into is that in `libc` we deliberately use
> `--target` to use a different device toolchain, which doesn't support
> some linker arguments passed via `-Wl`. This is observed in
> https://github.com/llvm/llvm-project/pull/73030 when attempting to use
> these options.
>
> This patch completely removes these default arguments.
>
> The consensus is that any issues created by this patch should ultimately
> be solved on a per-runtime basis.
This reverts commit ee922e6ebfb6aab722f6b0f7cfc0c20af636a250.
Part of fixes for #72913.
clang emits `DW_AT_alignment` attribute, however LLDB didn't respect it,
resulting in incorrect RecordDecls built by lldb.
This only fixes non-inheritance cases. The inheritance case will be
handled in a follow-up patch.
1. Rename the names of tables to simplify the print
2. Align the abbreviation in the same file Instr -> Inst
3. Clang-format
4. Capitalize the first char of the variable name
Split MatchDataInfo, CXXPredicates and the Pattern hierarchy into their
own files.
This should help with maintenance a bit, and make the API easier to
navigate.
I hope this encourages a bit more experimentation with MIR patterns,
e.g. I'd like to try getting them in ISel at some point.
Currently, this is pretty much only moving code around. There is no
significant refactoring in there.
I want to split the Combiner backend even more at some point though,
e.g. by separating the TableGen parsing logic into yet another file so
other backends could very easily parse patterns themselves.
Note: I moved the responsibility of managing string lifetimes into the
backend instead of the Pattern class.
e.g. Before you'd do `P.addOperand(Name)` but now it's
`P.addOperand(insertStrRef(Name))`.
I verified this was done correctly by running the tests with UBSan/ASan.
* Add a LinAlg pass to convert 2D convolutions and quantized 2D
convolutions that have the `FHWC` filter channel ordering into a
transpose followed by 2D convolutions that have the `HWCF` channel
ordering.
* Add a lit test to check the semantics of the transformation are
correct for both quantized and unquantized variants.
Signed-off-by: Jack Frankland <jack.frankland@arm.com>
...and follow ups.
As it has caused test failures on Linux Arm and AArch64:
https://lab.llvm.org/buildbot/#/builders/96/builds/49126https://lab.llvm.org/buildbot/#/builders/17/builds/45824
```
lldb-shell :: Subprocess/clone-follow-child-wp.test
lldb-shell :: Subprocess/fork-follow-child-wp.test
lldb-shell :: Subprocess/vfork-follow-child-wp.test
```
This reverts commit a6c62bf1a4717accc852463b664cd1012237d334,
commit a0a1ff3ab40e347589b4e27d8fd350c600526735 and commit
fc6b72523f3d73b921690a713e97a433c96066c6.
A splat packed constant can be folded as an inline immediate but it
shall use opsel. On gfx940 this code path can be skipped due to HW bug
workaround and then it may be folded w/o opsel which is a bug. Fixed.
The indexed compare fold converts comparisons of GEPs with same
(indirect) base into comparisons of offset. Currently, it only supports
GEPs with the same source element type.
This change makes the transform operate on offsets instead, which
removes the type dependence. To keep closer to the scope of the original
implementation, this keeps the limitation that we should only have at
most one variable index per GEP.
This addresses the main regression from
https://github.com/llvm/llvm-project/pull/68882.
TBH I have some doubts that this is really a useful transform (at least
for the case where there are extra pointer users, so we have to
rematerialize pointers at some point). I can only assume it exists for a
reason...
Store the ReverseChildren using node indices instead of node pointers.
This avoids some more hash table lookups.
I've also increased the size of the SmallVector from 2 to 4. As the
indices are half as large as the pointers (on 64bit) this keeps memory
usage the same as before. I've found the larger SmallVector to perform a
bit better.
This reverts commit 934efd2c9b9461bf79599cac3f57fc35cff978f7.
This relands commit 1449b349ac4072adb1f593234c1d6f67986d3b6a.
This build system fix was reverted as the underlying patch that required
the fix got reverted due to test failures on Darwin. The test failures
have since been fixed and the patch has relanded, so we need support in
Bazel again.
This PR suggests a way to fix
https://github.com/llvm/llvm-project/issues/70418. It now throws an
error if the `index` operand for `memref.dim` is out of bounds. Catching
it in the verifier was not possible because the constant value is not
yet available at that point. Unfortunately, the error is not very
descriptive since it was only possible to propagate boolean up.
1. Remove unused variables, e.g X86Subtarget object in performCustomAdjustments
2. Define checkVEXInstPredicate directly instead of generating it b/c
the function is small and it's unlikely we have more instructions to
check the predicate in the future
3. Check the tables are sorted only once for each function
4. Remove some blanks and clang-format code
This reverts commit ea5de6021cf69a233106689cc6f0ee14899e1a83.
This patch was reverted as it broke a test on x86_64 Darwin due to the
symbol naming being different between platforms. As Darwin isn't a
supported platform for executing snippets for llvm-exegesis, we can just
disable the test to fix the issue.
- Support non-member functions and callable objects for size and data().
We previously tried to (badly) pick the best overload ourselves, in a
way that would only support member functions. We now leave clang
construct an unresolved member expression and call that, properly
performing overload resolution with callable objects and static
functions, consistent with the logic for `get` calls for structured
bindings.
- Support UDLs as message expression.
- Add tests and mark CWG2798 as resolved
Found while running libc++'s test suite with MSVC's STL.
MSVC has a level 1 "warning C5101: use of preprocessor directive in
function-like macro argument list is undefined behavior". I don't know
why Clang doesn't complain about this.
There are some formatting tests which densely interleave preprocessor
directives within function-like macros, and they would need invasive
changes. For now, I'm just skipping those tests.
However, a few tests were only slightly affected, and I was able to add
a new test macro `TEST_IF_AIX` to make them portable.
Found while running libc++'s test suite with MSVC's STL.
MSVC's STL rejects `allocator<const T>`. This may or may not be
justified by the current Standardese (it was bogus in the C++03 era),
but it's how we reject usage like `vector<const T>`.
A bunch of `mdspan` tests are failing for us because some centralized
machinery is using `allocator<const T>`. Testing that `mdspan` and its
associated types work properly with `const T` is good and necessary, but
directly allocating `const T` is what's a problem for MSVC's STL. I'd
like to ask for a very targeted change here that preserves all of the
test coverage but changes how `ElementPool` interacts with `allocator`.
This intentionally leaves `ElementPool::get_ptr()` returning `T*`
(pointer-to-possibly-const), so there's no externally visible
difference.
Most libc_support_library calls are for header-only libraries, but there
are a few that have .cpp files. This patch adds the same base copts to
these that libc_function already has.
Following the discussions in this thread,
https://discourse.llvm.org/t/some-question-on-the-semantics-of-the-arith-dialect/74861,
here are some updates to the documented semantics of Arith.
Added are clarifications on poison behaviour, UBs, overflow semantics,
and the underlying two's complement representation used for integers
Co-authored-by: kuhar <jakubk@openxla.org>
Co-authored-by: math-fehr <mathieu.fehr@gmail.com>
The combine was implicitly assuming that the index on the outer
insert_subvector meant the same thing when the source was switched to be
the index of the inner insert_subvector. This is not true if the
innermost sub-vector is fixed, and the outer subvector is scalable.
I could do a less restrictive fix here - i.e. allow the case where the
scalability of the subvectors are the same - but there's no test
coverage which shows this transform actually has profit. Given that, go
for the simplest fix.
Moves sanitizer symbolizer code that is specific for
fuchsia into its own _fuchsia.cpp file.
This is preparation to enable symbolizer markup in
linux.
Reviewers: PiJoules, petrhosek, vitalybuka
Reviewed By: PiJoules, vitalybuka
Pull Request: https://github.com/llvm/llvm-project/pull/73192
