llvm-svn: 352732

This was accidentaly omitted from r352729 and broke lldb bots.

llvm-svn: 352731

Summary: This patch enables folding following expressions under -ffast-math flag: exp(X) * exp(Y) -> exp(X + Y), exp2(X) * exp2(Y) -> exp2(X + Y). Motivation: https://bugs.llvm.org/show_bug.cgi?id=35594

Reviewers: hfinkel, spatel, efriedma, lebedev.ri

Reviewed By: spatel, lebedev.ri

Subscribers: lebedev.ri, llvm-commits

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

llvm-svn: 352730

Previously, there were two different scripts for generating VCS headers:
one used by LLVM and one used by Clang. They were both similar, but
different. They were both broken in their own ways, for example the one
used by Clang didn't properly handle monorepo resulting in an incorrect
version information reported by Clang.

This change unifies two the scripts by introducing a new script that's
used from both LLVM and Clang, ensures that the new script supports both
monorepo and standalone SVN and Git setups, and removes the old scripts.

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

llvm-svn: 352729

Currently SCEV attempts to limit transformations so that they do not work with
big SCEVs (that may take almost infinite compile time). But for this, it uses heuristics
such as recursion depth and number of operands, which do not give us a guarantee
that we don't actually have big SCEVs. This situation is still possible, though it is not
likely to happen. However, the bug PR33494 showed a bunch of simple corner case
tests where we still produce huge SCEVs, even not reaching big recursion depth etc.

This patch introduces a concept of 'huge' SCEVs. A SCEV is huge if its expression
size (intoduced in D35989) exceeds some threshold value. We prohibit optimizing
transformations if any of SCEVs we are dealing with is huge. This gives us a reliable
check that we don't spend too much time working with them.

As the next step, we can possibly get rid of old limiting mechanisms, such as recursion
depth thresholds.

Differential Revision: https://reviews.llvm.org/D35990
Reviewed By: reames

llvm-svn: 352728

llvm-svn: 352725

llvm-svn: 352724

Rather than guessing whether to use static or shared version of
unwinder and c++abi when using linking against the in-tree versions,
provide a CMake option to control this.

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

llvm-svn: 352723

This change reverts r351626.

The changes in r351626 cause quadratic work in several cases. (See r351626 thread on llvm-commits for details.)

llvm-svn: 352722

Support for -fsanitize-coverage=trace-pc[-guard] was removed from
libFuzzer, which makes this currently fail.

This commit aligns this Darwin-specific test with its Linux counterpart
which changed in this commit:
https://github.com/llvm/llvm-project/commit/3a94519a777b9ac407a1d5ff5c31ec48b3768eec

llvm-svn: 352721

llvm-svn: 352720

llvm-svn: 352719

llvm-svn: 352718

For AMDGPU the result is always 32-bit for 64-bit inputs.

llvm-svn: 352717

Also fix an alignment bug getMachineMemOperand. If the
tracked value is null, the offset isn't tracked so the
base alignment needs to be reduced.

llvm-svn: 352716

llvm-svn: 352715

Added the checks to the existing cases when the target is Win64.

llvm-svn: 352714

[libFuzzer] set libFuzzer's own SEGV handler even one is already present, but call that handler from ours (unless we are unprotecting lazy counters). Call ProtectLazyCounters later, so that it runs after the initialization code in the target. 

llvm-svn: 352713

llvm-svn: 352712

Summary:
Set default `ASAN_OPTIONS` when running libFuzzer tests. This allows us
to remove special casing in code for Darwin where we usually pass
`abort_on_error=0` to override platform defaults for tests.

A previous commit changed the code to make the tests pass:
https://github.com/llvm/llvm-project/commit/7764a04af007eca68eafcf5caaea560ed05e35a9

Adapted a few tests to use `%env_asan_opts=` instead of directly setting
the environment variable.

rdar://problem/47515276

Reviewers: kcc, george.karpenkov

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

llvm-svn: 352711

llvm-svn: 352710

llvm-svn: 352709

[X86] Add a 32-bit command line to avx512-intrinsics.ll. Move all 64-bit mode only intrinsics to avx512-intrinsics-x86_64.ll.

Most of the other intrinsic tests have a 32-bit command lines.

llvm-svn: 352708

llvm-svn: 352707

One considers it integer division, the other doesn't.
Move to `//` (floor division) so that this test passes
independently from the version.

llvm-svn: 352706

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

llvm-svn: 352705

LLVMConfig.with_environment() uses os.path.normcase(os.path.normpath(x)) to
normalize temporary env vars. LLVMConfig.use_clang() uses with_environment() to
temporarily set PATH and then look for clang there. This means that on Windows,
clang will be run with a path like c:\foo\bin\clang.EXE (with a lower-case
"C:").

lit.util.which() used to not do this, which means the executables added in
clang/test/lit.cfg.py (e.g. c-index-test) were run with a path like
C:\foo\bin\c-index-test.EXE (because both CMake and GN happen to write
clang_tools_dir with an upper-case C to lit.site.cfg.py).

clang/test/Index/pch-from-libclang.c requires that both c-index-test and clang
use _exactly_ the same resource dir path (same case and everything), because a
hash of the resource directory is used as module cache path.

This patch is necessary but not sufficient to make pch-from-libclang.c pass on
Windows.

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

llvm-svn: 352704

This will ensure we don't rerun Sphinx when the files exist.

llvm-svn: 352703

Summary:
Fixes PR40267, in which the removed assertion was triggering on
perfectly valid IR. As far as I can tell, constant out of bounds
indices should be allowed when splitting extract_vector_elt, since
they will simply be propagated as out of bounds indices in the
resulting split vector and handled appropriately elsewhere.

Reviewers: aheejin

Subscribers: dschuff, sbc100, jgravelle-google, hiraditya

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

llvm-svn: 352702

So, we need an explicit call to decode() here to let it work with
both interpreters. Fixes TestXMMRegisters on 3.7.

llvm-svn: 352701

[libFuzzer] experimental performance optimization -lazy_counters, off by default. Posix-only for now, tested on Linux

llvm-svn: 352700

[LegalizeTypes] Use report_fatal_error instead of llvm_unreachable in the default case of some type legalization handlers that can be reached with intrinsics with result or operands that aren't legal types.

These can be triggered by mistakenly using a 64-bit mode only intrinsics with a -mtriple=i686. Using report_fatal_error gives a better experience for this mistake in release builds instead of probably crashing.

We already do this for some of the vector type legalization handles.

llvm-svn: 352699

I believe this was there to handle avx512bw intrinsics that returned i64 type in 32-bit mode. But all those intrinsics have since been changed to v64i1 results or replaced with generic IR.

llvm-svn: 352698

llvm-svn: 352697

This patch adds the lldb-docs target which generates the Sphinx html
documentation.

llvm-svn: 352696

Summary:
We planned to delete this intrinsic and do custom lowering from
`wasm.get.exception`, which has a token argument, to
`EXTRACT_EXCEPTION`, a wasm pseudo instruction that simulates popping a
value from the wasm stack.

To do that, we need to introduce a new `WebAssemblyISD` node for this,
which itself is not a problem, but also have to introduce the
`WebAssemblyISD` namespace in SelectionDAGBuilder.cpp. I don't think any
other targets are doing that in the file. And also putting a
target-specific intrinsic in the common file is a little weird too. (All
other intrinsic functions in this `visitIntrinsicCall` functions are not
target-specific ones. Other target-specific intrinsics are usually
handled in `lib/Target/[TargetName]/[TargetName]ISelLowering.cpp`. The
reason we can't do this is it has a token argument.

Anyway, so I think I prefer the current code with one redundant
intrinsic more than adding one more `WebAssemblyISD` node and
also introducing the `WebAssemblyISD` namespace into
SelectionDAGBuilder.cpp. What do you think?

Reviewers: dschuff

Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits

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

llvm-svn: 352695

ELF sections allow 0 for the alignment, which is specified to
be the same as 1.  However many clients do not expect this and
will behave poorly in the presence of a 0-aligned section (for
example by trying to modulo something by the section alignment).
We can be more polite by making sure that we always pass a
non-zero value to clients.

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

llvm-svn: 352694

Accidentally left this dependency out after D54438.

llvm-svn: 352693

This teaches the legalizer to handle G_FEXP in AArch64. As a result, it also
allows us to select G_FEXP.

It...

- Updates the legalizer-info tests
- Adds a test for legalizing exp
- Updates the existing fp tests to show that we can now select G_FEXP

https://reviews.llvm.org/D57483

llvm-svn: 352692

No test as it's a preventative fix.

llvm-svn: 352691