For use with APIs that want to report the file name in a different
syntactic form, have other knowledge of the filename, etc.

It's a common error in an API - to try to open an empty file, so it
seems like a reasonable FileError to produce "hey, you tried to open an
empty file" and to handle it the same way as any other file error.

This moves all the private implementation details to the bottom of
the header, and pushes all the "make an APInt" stuff up to the top.
This is in prep for making other changes to spiff up APInt a bit.

- Make flto an alias of flto=full.
- Make foffload-lto an alias of foffload-lto=full.
- Make flto_EQ_jobserver, flto_EQ_auto aliases of flto=full,
  since they are being treated as full lto right now.
- Clean up the code for parseLTOMode and setLTOMode.
- Replace uses of OPT_flto with OPT_flto_EQ since they alias now.

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

Change-Id: I5d867db83a680434fba5c8d85c9a83135d3b81ee

I forgot that we run `check-runtimes-x86_64-unknown-linux-gnu`, which
will run all compiler-rt tests also even though we are currently not in
a state where we can run them all yet. Remove this for now to fix our CI
builders.

This reverts commit d2d2e5ea.

- Make flto an alias of flto=full.
- Make foffload-lto an alias of foffload-lto=full.
- Make flto_EQ_jobserver, flto_EQ_auto aliases of flto=full,
  since they are being treated as full lto right now.
- Clean up the code for parseLTOMode and setLTOMode.
- Replace uses of OPT_flto with OPT_flto_EQ since they alias now.

Change-Id: Iea5338c20cb800b43529b20745e92600e2cfd2b1

We were returning a tuple when all but one caller only cared about one piece of the return value.  That one caller can inline the complexity, and we can simplify all other uses.

Previously the CodeExtractor created exit stubs, and the subsequent return value of the outlined function based on the order of out-of-region blocks after splitting any phi nodes, and collecting the blocks to be outlined. This could cause differences in order if there was a difference of exit block phi nodes between the two regions. This patch moves the collection of the output target blocks to be before this occurs, so that the assignment of target block to output value will be the same, regardless of the contents of the output block.

Reviewers: paquette, roelofs

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

Rewrite this test to not rely on volatile stores in a large function,
just use separate functions like any other test would.

Reviewed By: asbirlea

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

Since i128 isn't a legal C type on RV32, I don't believe
libgcc implements these functions for RV32. compiler-rt
does implement them because i128 support is enabled
in order to handle long double.

This is consistent with 32-bit X86 and ARM.

Reviewed By: efriedma

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

Users of delinearization assume that the the offset into the array element is zero. In most cases it will indeed be zero, but if it is not, the delinearization has to fail since it violates that assumption without the API even allowing to signal to the caller that the by offset is non-zero.

This bug caused Polly to miscompile blender (526.blender_r from SPEC CPU 2017) in -polly-process-unprofitable mode. The SCEV expression incorrectly delinearized has been reduced in the test case byte_offset.ll. The dropped offset into the array element of size 4 (a float) is ((sext i32 %mul7.i4534 to i64) + {(sext i32 %i1 to i64),+,((sext i32 (1 + ((1 + %shl.i.i) * (1 + %shl.i.i)) + %shl.i.i) to i64) * (sext i32 %i1 to i64))}<%for.body703>). This significant component was just dropped, and the wrong pointer was computed when regenerating code from the remaining delinearized subscripts. This occurred during blender's subsurface scattering implementation. As a result, blender's rendering diverged from the reference image.

Patch D108885 would also fix the API.

Reviewed By: bmahjour

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

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

These paths are needed when building with per-target runtime directories.

(It's possible to fix this by manually setting these when invoking
cmake, but one isn't supposed to need to do that.)

Also set LLVM_TOOLS_BINARY_DIR while touching this area (as it's
also unset in this case) even if it isn't specifically needed by the
per-target runtime configuration.

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

Since we might end up using multiple threads when logging information in the DWARFTransformer, the handleDie() method must use the supplied stream named "OS" when logging warnings and errors. When we use multiple threads, we log to a thread specific stream buffer and then use a mutex to ensure our output doesn't overlap when we emit warnings and errors after a thread is done.

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

Make sure there's a value for the shared_cache_base_address key exists
in the dictionary before trying to dereference the value.

rdar://76894476

The OrigPtr argument is not used in tree.

This patch (e4635e63) fixed a bug where a newly generated/reused
constant wouldn't dominate a folded operation.  It did so by calling
isBeforeInBlock to move the constant around on demand.  This introduced
a significant compile time regression, because "isBeforeInBlock" is
O(n) in the size of a block the first time it is called, and the cache
is invalidated any time canonicalize changes something big in the block.

This fixes LLVM PR51738 and this CIRCT issue:
https://github.com/llvm/circt/issues/1700

This does affect the order of constants left in the top of a block,
I staged in the testsuite changes in rG42431b82.

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

by commit 585c594d

Make the following changes in order to support opaque pointers in SROA:

 * Generate i8 GEPs for opaque pointers.
 * Explicitly enforce that promotable allocas only have stores of
   the alloca type -- previously this was implicitly enforced.
 * Replace a check for pointer element type with load/store type.

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

The current check for typedef is naive and doesn't deal with any convoluted cases. This patch makes use of the new 'AlignRequirement' enum field from 'TypeInfo' to determine whether or not this is an 'aligned' attribute on a typedef.

Reviewed By: rjmccall

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

The implementation is mostly copied from MemDepAnalysis. We want to look
at all loads and stores to the same pointer operand. Bitcasts and zero
GEPs of a pointer are considered the same pointer value. We choose the
most dominating instruction.

Since updating MemorySSA with invariant.group is non-trivial, for now
handling of invariant.group is not cached in any way, so it's part of
the walker. The number of loads/stores with invariant.group is small for
now anyway. We can revisit if this actually noticeably affects compile
times.

To avoid invariant.group affecting optimized uses, we need to have
optimizeUsesInBlock() not use invariant.group in any way.

Co-authored-by: Piotr Padlewski <prazek@google.com>

Reviewed By: asbirlea, nikic, Prazek

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

This commit partially reverts 0954e2b2 and 3fa4cff9, which
make changes to the libc++ documentation implifying that OpenBSD is
supported. Neither of these changes have been reviewed AFAICT, so
I'm reverting as a matter of enforcing:

1. That changes get reviewed before being committed
2. That we have a discussion and a support plan for supporting
   OpenBSD officially in libc++

Please note that I would be thrilled to support OpenBSD officially in
libc++, however doing so requires more than adding a note in the docs.
In particular, please make sure you read the note in [1] about setting
up CI testing for OpenBSD.

[1]: https://libcxx.llvm.org/#platform-and-compiler-support

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

None of this logic has anything to do with SCEV's internals, it just uses the existing public APIs.  As a result, we can move the code from ScalarEvolution.cpp/hpp to Delinearization.cpp/hpp with only minor changes.

This was discussed in advance on today's loop opt call.  It turned out to be easy as hoped.

Directly use i8 for GEP, rather than fetching element type of i8*.

In other places in the code, we use lowercase spelling for things that
are not available in prior standards.

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

integer 0/1 for the operand of bundle "clang.arc.attachedcall"

https://reviews.llvm.org/D102996 changes the operand of bundle
"clang.arc.attachedcall". This patch makes changes to llvm that are
needed to handle the new IR.

This should make it easier to understand what the IR is doing and also
simplify some of the passes as they no longer have to translate the
integer values to the runtime functions.

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

integer 0/1 for the operand of bundle "clang.arc.attachedcall"

This should make it easier to understand what the IR is doing and also
simplify some of the passes as they no longer have to translate the
integer values to the runtime functions.

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

Fixes a build error caused by a bad merge conflict resolution for
https://reviews.llvm.org/D105084.

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

Before, COMPILER_RT_TEST_COMPILER was used which pointed to a C compiler. While
it is incorrect to assume either of these is the default compiler, using the
C++ one allows for linking cpp tests.

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

D104143 introduced canonical value numbering between regions, which allows for the easy identification of items across a region, eliminating the need in the outliner to create parallel lists of instructions for each region, and replace output values in a less convoluted way.

Additionally, in a future commit, the output values will not necessarily be recorded values from the region itself, it could be a combination value where the actual value being output is a PHINode instead.  This new method allows us to handle the replacement of the output value to the stored value with the corresponding item in the same place for both normal output values, and PHINode outputs instead of handling the different types of outputs in different locations.

Reviewers: paquette, roelofs

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

This patch changes SPMDization to not trigger for regions with no
parallelism. Otherwise, this will introduce unnecessary barriers that
will slow the single-threaded region down.

Reviewed By: jdoerfert

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

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

IRExecutionUnit::SearchSpec is a struct that encapsulates information
needed to look for a symbol. Specifically, it is comprised of a name
represented with a ConstString and a FunctionNameType mask.
Because the mask is unused (effectively always set to
eFunctionNameTypeFull), we can remove the mask and replace all uses with
eFunctionNameTypeFull.  After doing that, SearchSpec is effectively a
wrapper around a ConstString.

As an aside, SearchSpec is similar in purpose to Module::LookupInfo. I
briefly considered replacing uses of SearchSpec with LookupInfo, but
the current code only cares about symbol names (treating them as
eFunctionNameTypeFull). This code does care about language type, so
LookupInfo may be appropriate for IRExecutionUnit in the future.

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