If the income state hasn't changed, and the step function is fixed by assumption, then the output state can't have changed.
In the current algorithm, this is a very minor win and mostly allows adding tracing output without being horrible verbose.
That makes it possible to reuse libc++abi targets from the libc++
configuration, which is necessary to allow major CMake simplifications.
As a fly-by fix, we also unify how compiler-rt ordering is handled so
it matches how libc++ and libc++abi are handled (compiler-rt always
ends up first).
Differential Revision: https://reviews.llvm.org/D120719
The LLVM ThreadPool recently got the addition of the concept of
ThreadPoolTaskGroup: this is a way to "partition" the threadpool
into a group of tasks and enable nested parallelism through this
grouping at every level of nesting.
We make use of this feature in MLIR threading abstraction to fix a long
lasting TODO and enable nested parallelism.
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D124902
This patch is a followup to the previous patch which implemented the
main printf parsing logic as well as sequential mode. This patch adds
index mode.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D123424
This check verifies the safety of access to `std::optional` and related
types (including `absl::optional`). It is based on a corresponding Clang
Dataflow Analysis, which does most of the work. This check merely runs it and
converts its findings into diagnostics.
Differential Revision: https://reviews.llvm.org/D121120
fcgl option will make compilation stop after clang codeGen and output the llvm ir.
It is added to check clang codeGen output for HLSL.
It will be translated into -S -emit-llvm and -disable-llvm-passes.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D124983
The entrypoint list for windows hasn't been updated in a while, this
adds all of the entrypoints that are working for windows now.
Reviewed By: sivachandra, lntue
Differential Revision: https://reviews.llvm.org/D125058
This testcase runs slowly due to 3.2s of sleeps = 2 + 1 + 0.2s.
After this patch it has 0.55s only.
Reduced by:
- observed that the last test was bogus: we were sleeping until the queue was
idle, effectively just a second copy of the first test. This avoids 1s sleep.
- when waiting for debounce, sleep only until test passes, not for enough
time to be safe (in practice was 2x debounce time, now 1x debounce time)
- scaling delays down by a factor of 2 (note: factor of 10 caused bot failures)
Differential Revision: https://reviews.llvm.org/D125103
13403a70e4 introduced a bug where we
generate the outgoing carry inverted, which in turn breaks the
lowering of @llvm.usub.sat.i128, returning the normal difference on
saturation and zero otherwise.
Note that AArch64 has peculiar semantics where the subtraction
instructions generate borrow inverted. The problem is that we mix the
two forms of semantics -- the normal carry and inverted carry -- in
the area of extended precision subtractions. Specifically, we have
three problems:
- lowerADDSUBCARRY takes the non-inverted incoming carry from a
subtraction and feeds it to SBCS without inverting it first.
- lowerADDSUBCARRY makes available the outgoing carry from SBCS
without inverting it.
- foldOverflowCheck folds:
(SBC{S} l r (CMP (CSET LO carry) 1)) => (SBC{S} l r carry)
When the incoming carry flag is set, CSET LO results in zero. CMP
in turn generates a borrow, *clearing* the carry flag. Instead, we
should fold:
(SBC{S} l r (CMP 0 (CSET LO carry))) => (SBC{S} l r carry)
When the incoming carry flag is set, CSET LO results in zero. CMP
does not generate a borrow, *setting* the carry flag.
IIUC, we should use the normal (that is, non-inverted) semantics for
carry everywhere.
This patch fixes the three problems above.
This patch does not add any new testcases because we have a plenty of
them covering the instruction in question. In particular,
@u128_saturating_sub is identical to the testcase in the motivating
issue.
Fixes: #55253
Differential Revision: https://reviews.llvm.org/D124976
Something is going wrong with the BigEndian PowerPC bot. It is hard to
tell what is wrong from here, but attempt to fix it by disabling the
combineShuffleOfBitcast combine for bigendian.
This assertion should hold for any reasonable data flow algorithm, but is known not to in several cases today. I'd like to go ahead and land this off-by-default, so that we can collaborate on fixes and have a common definition of success.
Differential: https://reviews.llvm.org/D125035
This adds some extra costs for reverse shuffles under AArch64, filling
in the i16/f16/i8 gaps in the cost model.
Differential Revision: https://reviews.llvm.org/D124786
Add tests exercising the future enancement of folding library function
calls with arguments involving subobjects such as elements of arrays
or struct members.
This method won't add a check if it isn't supported in the Contexts current LanguageOptions.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D124320
Otherwise we have garbage in the upper bits that can affect the
results of the UREM.
Fixes PR55296.
Differential Revision: https://reviews.llvm.org/D125076
The code below causes flang to crash with an exception.
After fixing the crash flang with an internal error "no symbol found for 'bar'"
This change fixes all the issues.
program name
implicit none
integer, parameter :: bar = 1
integer foo(bar) /bar*2/
end program name
Reviewed By: kiranchandramohan, klausler
Differential Revision: https://reviews.llvm.org/D124914
Currently we handle static libraries like any other object in the
linker wrapper. However, this does not preserve the sematnics that
dictate static libraries should be lazily loaded as the symbols are
needed. This allows us to ignore linking in architectures that are not
used by the main application being compiled. This patch adds the basic
support for detecting if a file came from a static library, and only
including it in the link job if it's used by other object files.
This patch only adds the basic support, to be more correct we should
check the symbols and only inclue the library if the link job contains
symbols that are needed. Ideally we could just put this on the linker
itself, but nvlink doesn't seem to support `.a` files.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D125092
Placing a non-SHT_NOBITS input section in an output section specified with
(NOLOAD) is fishy but used by some projects. D118840 changed the output type to
SHT_PROGBITS, but using the specified type seems to make more sense and improve
GNU ld compatibility: `(NOLOAD)` seems to change the output section type
regardless of input.
I think we should keep the current type mismatch warning as it does indicate an
error-prone usage.
Reviewed By: peter.smith
Differential Revision: https://reviews.llvm.org/D125074
As Fortran 2018 states, in each where-assignment-stmt, the mask-expr and
the variable being defined shall be arrays of the same shape. The
previous check does not consider checking if it is an array.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D125022
As Fortran 2018 15.5.2.9 point 2, the actual argument and dummy argument
have the same type and type parameters and an external function with
assumed character length may be associated with a dummy argument with
explicit character length. As Fortran 2018 15.5.2.9 point 7, if an
external procedure is used as an actual argument, it can be explicitly
declared to have the EXTERNAL attribute. This supports the external
procedure passed as actual argument with implicit character type, either
explicit character length or assumed character length.
Reviewed By: Jean Perier, klausler
Differential Revision: https://reviews.llvm.org/D124345
Philip Reames