On my 96-core cloudtop 'machine', it seems unnecessary to always start
96 threads upfront... particularly as the ThreadPool is created even
with -mlir-disable-threading. Things like the resuling spew in GDB and
the obfuscated output of `(gdb) info threads` are my motivation here,
but it probably also doesn't hurt for at least some efficiency metrics to
avoid creating many threads upfront.
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D115019
As mentioned in D106585, this causes non-determinism, which can also be
shown by this test case being flaky without this patch.
We were using the APSInt's bit width for hashing, but not for checking
for equality. APInt::isSameValue() does not check bit width.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D115054
Upon testing the use of test-release.sh on AIX, the script initially fails
because chrpath is not present on AIX. This patch adds checks for AIX and allows
the script to continue running to completion.
Differential Revision: https://reviews.llvm.org/D115046
It's very simple, fast and efficient for the stack depot compression if used on entire pointers.
Reviewed By: morehouse, kstoimenov
Differential Revision: https://reviews.llvm.org/D114918
Using `_mkdir` of CRT in Asan Init leads to launch failure and hanging in Windows.
You can trigger it by calling:
> set ASAN_OPTIONS=log_path=a/a/a
> .\asan_program.exe
And their crash dump shows the following stack trace:
```
_guard_dispatch_icall_nop()
__acrt_get_utf8_acp_compatibility_codepage()
_mkdir(const char * path)
```
I guess there could be a cfg guard in CRT, which may lead to calling uninitialized cfg guard function address. Also, `_mkdir` supports UTF-8 encoding of the path and calls _wmkdir, but that's not necessary for this case since other file apis in sanitizer_win.cpp assumes only ANSI code case, so it makes sense to use CreateDirectoryA matching other file api calls in the same file.
Reviewed By: tejohnson
Differential Revision: https://reviews.llvm.org/D114760
Add -NOT lines to ensure that no extra passes are run if
-extra-vectorizer-passes is not specified.
Also add a loop that actually gets vectorized in preparation for
D115052.
With C++17 the exception specification has been made part of the
function type, and therefore part of mangled type names.
However, it's valid to convert function pointers with an exception
specification to function pointers with the same argument and return
types but without an exception specification, which means that e.g. a
function of type "void () noexcept" can be called through a pointer
of type "void ()". We must therefore consider the two types to be
compatible for CFI purposes.
We can do this by stripping the exception specification before mangling
the type name, which is what this patch does.
Differential Revision: https://reviews.llvm.org/D115015
It's possible for this test not to pass if the libc used does not provide
unwind info for raise. We can replace it with __builtin_cast, which can lead
to a SIGTRAP on x86_64 and a SIGILL on aarch64.
Using this alternative, a nop is needed before the __builtin_cast. This is
because libunwind incorrectly decrements pc, which can cause pc to jump into
the previous function and use the incorrect FDE.
Differential Revision: https://reviews.llvm.org/D114818
When Control Flow Guard Check is inserted, funclet bundle was not checked. Therefore, it didn't generate code correctly when a target function has "funclet" bundle.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D114914
Google-signed apexes appear on Android build servers' symbol files as
being under /apex/com.google.android.<foo>/. In reality, the apexes are
always installed as /apex/com.android.<foo>/ (note the lack of
'google'). In order for local symbolization under hwasan_symbolize to
work correctly, we also try the 'google' directory.
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D114919
Two-address pass works right before RA and if an immediate
was folded into an instruction there is nothing to remove
the dead def. We end up with something like:
v_mov_b32_e32 v14, 0xc1700000
v_mov_b32_e32 v14, 0x41200000
v_fmaak_f32 v51, s67, v19, 0xc1700000
v_fmaak_f32 v38, v51, v19, 0x4120000
The patch kills the dead move instruction right in the folding.
Differential Revision: https://reviews.llvm.org/D114999
This fixes a bug in 740057d. There's two ways to describe the issue:
* One caller hasn't yet proven nocapture on the argument. Given that, the inference routine is responsible for bailing out on a potential capture.
* Even if we know the argument is nocapture, the access inference needs to traverse the exact set of users the capture tracking would (or exit conservatively). Even if capture tracking can prove a store is non-capturing (e.g. to a local alloc which doesn't escape), we still need to track the copy of the pointer to see if it's later reloaded and accessed again.
Note that all the test changes except the newly added ones appear to be false negatives. That is, cases where we could prove writeonly, but the current code isn't strong enough. That's why I didn't spot this originally.
Helps appease MSVC which is complaining about "fatal error C1061: compiler limit: blocks nested too deeply" - we already do the same thing for avx512.mask.store intrinsics.
This is only a stopgap solution until another else-if case needs adding - we really need to refactor this chain of ifs properly.
minidebuginfo-set-and-hit-breakpoint.test is failing on Arm/Linux most
probably due to an ill formed binary after removal of certain sections
from executable. I am marking it as XFAIL for further investigation.
Try to appease the microsoft compiler which is apparently running out of
if statements. Separate the new ARM code into a separate function to
keep it simpler.
I'm not having a lot of luck with the microosft compiler recently. Maybe
this will help it with its errors:
llvm\lib\IR\AutoUpgrade.cpp(3726): fatal error C1061: compiler limit: blocks nested too deeply
If not, it's a good code cleanup anyway.
In release+sym builds (-O2 -g), reduces time to link `clang`
from 2.3s to 1.3s (-42%).
In debug builds (-g), reduces time to link `clang`
from 5.4s to 4.5s (-17.4%).
See the phab review for full `ministat` numbers.
In the CMake build this is opt-in via LLVM_USE_SPLIT_DWARF.
Since the GN build is targeted at developers, enabling it by default
seems like a better default setting here. (If it turns out to cause
problems, we can add an opt-out.)
Time to load the binary into gdb and to set a breakpoint is unchanged.
Time from `run` to hitting a breakpoint in `main` feel a bit faster
(~4s -> ~2s), but I dind't do a careful statistical anlysis for this.
Differential Revision: https://reviews.llvm.org/D115040
We want to simplify the build system and rely on code to do the implementation selection.
This is in preparation of adding a Bazel configuration (D114712).
Differential Revision: https://reviews.llvm.org/D115034
Prior to this patch, tail duplication handled debug info poorly -
specifically, debug instructions would be dropped instead of being set
undef, potentially extending the lifetimes of prior debug values that
should be killed. The pass was also very aggressive with dropping debug
info, dropping debug info even when the SSA value it referred to was
still present. This patch attempts to handle debug info more carefully,
checking to see whether each affected debug value can still be live,
setting it undef if not.
Reviewed By: jmorse
Differential Revision: https://reviews.llvm.org/D106875
This adjusts all the MVE and CDE intrinsics now that v2i1 is a legal
type, to use a <2 x i1> as opposed to emulating the predicate with a
<4 x i1>. The v4i1 workarounds have been removed leaving the natural
v2i1 types, notably in vctp64 which now generates a v2i1 type.
AutoUpgrade code has been added to upgrade old IR, which needs to
convert the old v4i1 to a v2i1 be converting it back and forth to an
integer with arm.mve.v2i and arm.mve.i2v intrinsics. These should be
optimized away in the final assembly.
Differential Revision: https://reviews.llvm.org/D114455
The Power ISA defined l[bhwdq]arx as both base and
extended mnemonics. The base mnemonic takes the EH
bit as an operand and the extended mnemonic omits
it, making it implicitly zero. The existing
implementation only handles the base mnemonic when
EH is 1 and internally produces a different
instruction. There are historical reasons for this.
This patch simply removes the limitation introduced
by this implementation that disallows the base
mnemonic with EH = 0 in the ASM parser.
This resolves an issue that prevented some files
in the Linux kernel from being built with
-fintegrated-as.
Also fix a crash if the value is not an integer immediate.
The earlier usage of wouldInstructionBeTriviallyDead is based on the
assumption that the use_count of that instruction being checked will be
zero. This patch separates the API into two different ones:
1. The strictly conservative one where the instruction is trivially dead iff the uses are dead.
2. The slightly relaxed form, where an instruction is dead along paths where it is not used.
The second form can be used in identifying instructions that are valid
to sink down to uses (D109917).
Reviewed-By: reames
Differential Revision: https://reviews.llvm.org/D114647
Need to do the analysis of the captured expressions in the clauses.
Previously the compiler ignored them and it may lead to a compiler crash
trying to get the address of the mapped variables.
Differential Revision: https://reviews.llvm.org/D114546
BufferizationState had map/lookup overloads for non-tensor values. This was necessary for IREE. There is now a better way to do this, so these overloads can be removed.
Differential Revision: https://reviews.llvm.org/D114929
MVE can treat v16i1, v8i1, v4i1 and v2i1 as different views onto the
same 16bit VPR.P0 register, with v2i1 holding two 8 bit values for the
two halves. This was never treated as a legal type in llvm in the past
as there are not many 64bit instructions and no 64bit compares. There
are a few instructions that could use it though, notably a VSELECT (as
it can handle any size using the underlying v16i8 VPSEL), AND/OR/XOR for
similar reasons, some gathers/scatter and long multiplies and VCTP64
instructions.
This patch goes through and makes v2i1 a legal type, handling all the
cases that fall out of that. It also makes VSELECT legal for v2i64 as a
side benefit. A lot of the codegen changes as a result - usually in way
that is a little better or a little worse, but still expensive. Costs
can change a little too in the process, again in a way that expensive
things remain expensive. A lot of the tests that changed are mainly to
ensure correctness - the code can hopefully be improved in the future
where it comes up in practice.
The intrinsics currently remain using the v4i1 they previously did to
emulate a v2i1. This will be changed in a followup patch but this one
was already large enough.
Differential Revision: https://reviews.llvm.org/D114449
This patch adds the FIR builder to generate the numeric intrinsic
runtime call.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: rovka
Differential Revision: https://reviews.llvm.org/D114900
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: mleair <leairmark@gmail.com>
This patch adds the builder to generate derived type runtime API calls.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: rovka
Differential Revision: https://reviews.llvm.org/D114472
Co-authored-by: Peter Klausler <pklausler@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
As discussed on D114589 as the constant case gets affected by SimplifyDemandedBits a lot - the non-constant case currently falls back to copysignl libcalls
Add clamp combine. Source is fminnum(fmaxnum(Val, 0.0), 1.0) or
fmaxnum(fminnum(Val, 1.0), 0.0) or fmed3 intrinsic with 0.0 and
1.0 as two out of three operands.
Differential Revision: https://reviews.llvm.org/D90052
Add floating point version of med3 combine.
Source is fminnum(fmaxnum(Val, K0), K1) or fmaxnum(fminnum(Val, K1), K0)
where K0 and K1 are constants and K0 <= K1.
Differential Revision: https://reviews.llvm.org/D90051
Recognize constant splat padded with undef in isCanonicalized.
Fcanonicalize will be removed by RemoveFcanonicalize in post-legalizer
combiner. We will treat undef as value that will result in a splat
in clamp combine after regbankselect.
Differential Revision: https://reviews.llvm.org/D104408
Benoit Jacob