DAG: Use RuntimeLibcalls to legalize vector frem calls
This continues the replacement of TargetLibraryInfo uses in codegen
with RuntimeLibcallsInfo started in 821d2825a4f782da3da3c03b8a002802bff4b95c.
The series there handled all of the multiple result calls. This
extends for the other handled case, which happened to be frem.
For some reason the Libcall for these are prefixed with "REM_", for
the instruction "frem", which maps to the libcall "fmod".
DAG: Avoid asserting on libcall action if function is unavailable
Eventually the set of available functions will be a program
dependent property, which could diverge from the static table of
functions for the subtarget. In that case, fall back to the usual
expansion.
DAG: Add overload of makeLibCall which calls an RTLIB::LibcallImpl
Logically the concrete implementation is what's being called, not
the abstract libcall. Many uses conditionalize emitting the call on
whether the call is available, so the caller and makeLibCall would
both be checking that.
AMDGPU: Avoid crashing on statepoint-like pseudoinstructions
At the moment the MIR tests are somewhat redundant. The waitcnt
one is needed to ensure we actually have a load, given we are
currently just emitting an error on ExternalSymbol. The asm printer
one is more redundant for the moment, since it's stressed by the IR
test. However I am planning to change the error path for the IR test,
so it will soon not be redundant.
Revert "Refactor WIDE_READ to allow finer control over high-performance function selection" (#170717)
Reverts llvm/llvm-project#165613
Breaks build bot
[Flang][OpenMP] Only allow implicit mappers for Allocatables. (#170701)
Generate implicit declare mappers only for Allocatables.
Fixes #169382 introduced by #140562.
Refactor WIDE_READ to allow finer control over high-performance function selection (#165613)
[This is more of a straw-proposal than a ready-for-merging PR. I got
started thinking about what this might look like, and ended up just
implementing something as a proof-of-concept. Totally open to other
methods an ideas.]
As we implement more high-performance string-related functions, we have
found a need for better control over their selection than the big-hammer
LIBC_CONF_STRING_LENGTH_WIDE_READ. For example, I have a memchr
implementation coming, and unless I implement it in every variant, a
simple binary value doesn't work.
This PR makes gives finer-grained control over high-performance
functions than the generic LIBC_CONF_UNSAFE_WIDE_READ option. For any
function they like, the user can now select one of four implementations
at build time:
1. element, which reads byte-by-byte (or wchar by wchar)
[13 lines not shown]
[clang-doc] Add Mustache case to assets test (#170198)
Mustache wasn't tested in the assets lit test, which tests if
user-supplied assets are copied correctly. The Mustache HTML backend
initialy failed this test because it expected every asset, which
included Mustache templates, to be supplied. For now, we just expect
either CSS or JS to be supplied and use the default if one of them isn't
given.
We can allow custom templates in the future using the same checks.
[clang-doc] Add Mustache case to assets test
Mustache wasn't tested in the assets lit test, which tests if
user-supplied assets are copied correctly. The Mustache HTML backend
initialy failed this test because it expected every asset, which
included Mustache templates, to be supplied. For now, we just expect
either CSS or JS to be supplied and use the default if one of them isn't
given.
We can allow custom templates in the future using the same checks.
[clang-doc] Add Mustache case to test for DR 131697 (#170197)
The test for DR 131697 only requires that clang-doc doesn't crash. There
is no documentation created. However, when using Mustache, clang-doc
still expects certain
paths to exist, like the directory where assets are placed. In legacy
HTML, the `docs` directory is still created and assets are placed there
regardless of there being any Infos to document. Mustache didn't do
this, so now we create `docs/json` and `docs/html` even if there is
nothing to document.
[ExposeObjCDirect] Setup helper functions
1. GenerateDirectMethodsPreconditionCheck: Move some functionalities to a separate functions.
Those functions will be reused if we move precondition checks into a thunk
2. Create `DirectMethodInfo`, which will be used to manage true implementation and its thunk
[JumpThread] Fix `JumpThreading` pass to skip merging when both blocks contain convergence loop/entry intrinsics. (#170247)
Fixes: https://github.com/llvm/llvm-project/issues/165642. After this
fix, optimization passes for the example in the bug.
[LLVM
Spec](https://llvm.org/docs/ConvergentOperations.html#llvm-experimental-convergence-loop)
states that only a single loop / entry convergence token can be included
in a basic block.
This PR fixes the issue in `JumpThreading` pass so that when a basic
block and its predecessor both contain such convergence intrinsics, it
skips merging the two blocks.
[clang-doc] Add Mustache case to assets test
Mustache wasn't tested in the assets lit test, which tests if
user-supplied assets are copied correctly. The Mustache HTML backend
initialy failed this test because it expected every asset, which
included Mustache templates, to be supplied. For now, we just expect
either CSS or JS to be supplied and use the default if one of them isn't
given.
We can allow custom templates in the future using the same checks.
[InferAttrs] Handle roundeven like other libm functions (#170691)
It was previously missing entirely. It behaves like floor, ceil, round,
and trunc, having no side effects.
