I'm not too sure how to get isel to select even all of the unmasked forms, but at least we have a consistent set now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291368 91177308-0d34-0410-b5e6-96231b3b80d8
Fixed missing checks for tests that used a '-' in the name, which was messing with update_llc_test_checks.py
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291363 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The issue happens with:
%0 = ....., !tbaa !0
%1 = ....., !tbaa !1
With !0 that references !1.
In this case when loading !0 we generates a temporary for the
operand !1. We now flush it immediately and trigger the load of
!1 before moving on. If we don't we get the temporary when
attaching to %1. This is usually not an issue except that we
eagerly try to update TBAA MDNodes, which is obviously not possible
if we only have a temporary.
Differential Revision: https://reviews.llvm.org/D28423
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291362 91177308-0d34-0410-b5e6-96231b3b80d8
Don't print a line multiple times, each for different inlining contexts, if
nothing happened in any context. This prevents situations like this:
[[
> main:
65 | if ((i * ni + j) % 20 == 0) fprintf
> print_array:
65 | if ((i * ni + j) % 20 == 0) fprintf
]]
which could happen if different optimizations were missed in different inlining
contexts.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291361 91177308-0d34-0410-b5e6-96231b3b80d8
fabs(x * x) is not generally safe to assume x is positive if x is a NaN.
This is also less general than it could be, so this will be replaced
with a transformation on the intrinsic.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291359 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Prior to this change, phi nodes were never considered defs, and so we ended up with undefined variables for any loop. Now, instead of trying to find just defs, we iterate over each actual IR value in the line, and replace them one by one with either a definition or a use.
We also don't try to match anything in the comment portions of the line.
I've tested it even on things like function pointer calls, etc, and against existing test cases uses update_test_checks
With this change, we are able to use update_tests on the cyclic cases in newgvn.
The only case i'm aware of that will misfire is if you have a string with which contains a valid token.
However, this is the same as it is now, with a slightly larger set of strings that may misfire.
Prior to this change, a test with the string " %a =" would be replaced.
Reviewers: spatel, chandlerc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D28384
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291357 91177308-0d34-0410-b5e6-96231b3b80d8
Tar's Ustar header has the "prefix" field to store a directory
part of a filename. It is not as flexible as the PAX-extended
filename because there's still a limitation on the maximum filename
size, but it mitigates the situation.
This patch should unbreak some Windows buildbots that uses very
old tar command.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291340 91177308-0d34-0410-b5e6-96231b3b80d8
Gracefully leave code that performs function-pointer bitcasts implying
non-trivial pointer conversions alone, rather than aborting, since it's
just undefined behavior.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291326 91177308-0d34-0410-b5e6-96231b3b80d8
With r291169, it is now not possible to access the live-in information
when the liveness is not properly tracked. Although this is want we want
in general, for debugging purpose we may want to still be able to
traverse this information even if it may not be accurate.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291317 91177308-0d34-0410-b5e6-96231b3b80d8
WebAssembly requires caller and callee signatures to match exactly. In LLVM,
there are a variety of circumstances where signatures may be mismatched in
practice, and one can bitcast a function address to another type to call it
as that type. This patch adds a pass which replaces bitcasted function
addresses with wrappers to replace the bitcasts.
This doesn't catch everything, but it does match many common cases.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291315 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: LLVM's non-standard notion of phi nodes means we can't both try to substitute for undef in phi nodes *and* use phi nodes as leaders all the time. This changes NewGVN to use the same semantics as SimplifyPHINode to decide which phi nodes are equivalent.
Reviewers: davide
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D28312
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291308 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
r285871 introduced an assert that was overly aggressive in the case
of a same-named local in different same-named files (in different
directories), where the source name and therefore the GUID ended up
the same because the files were compiled in their own directory without
any leading path. Change the handling in the promotion logic to get
the summary for the version in that module.
This also exposed an issue where we are not always importing the
right copy, which is a performance not correctness issue (because
the renaming is based on the module hash which must be different,
see the bug report for details). I will fix that as a follow-on.
Fixes PR31561.
Reviewers: mehdi_amini
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D28411
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291304 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
In order to simplify distributed build system integration, where actions
may be scheduled before the Thin Link which determines the list of
objects selected by the linker. The gold plugin currently will emit
0-sized index files for objects not selected by the link, to enable
checking for expected output files by the build system. If the build
system then schedules a backend action for these bitcode files, we want
to be able to fall back to normal compilation instead of failing.
This is the LLVM side support for optionally enabling fallback
instead of issuing an error. Return a null CombinedIndex from
llvm::getModuleSummaryIndexForFile under the option when the file
is empty. Clang can then ignore the index when it is null.
Clang patch is D28362.
Reviewers: mehdi_amini
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D28410
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291302 91177308-0d34-0410-b5e6-96231b3b80d8
Some GCC versions will accept any warning flag name after a '-Wno-',
which would cause us to try to disable warnings with names GCC didn't
understand. This will silently succeed unless there is some other output
from GCC in which case we get weird cc1plus warnings about the warning
name being bogus.
There is still the issue that gtest sets warning flags for building
gtest-all.cc using weird 'add_definitions' and the fact that there is
a GCC version which warns on the variadic macro usage in gtest under
-pedantic, but has no flag analogous to Clang's
-Wgnu-zero-variadic-macro-argumnets to suppress this warning. I haven't
been able to come up with any good solution here. The closest is to turn
off -pedantic for those versions of GCC, but that seems really nasty.
For now, those versinos of GCC aren't warning clean. If anyone is broken
by this, I'll work on CMake logic to detect and disable -pedantic in
these cases.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291299 91177308-0d34-0410-b5e6-96231b3b80d8
Modify the --system-libs option in llvm-config to print system libs only
when using static linking. The system libraries are irrelevant when
linking to a shared library since the library has appropriate library
dependencies embedded.
Modify the --system-libs test appropriately to force static linking, and
disable it if static libs are not available (i.e. BUILD_SHARED_LIBS is
enabled).
Differential Revision: https://reviews.llvm.org/D27805
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291285 91177308-0d34-0410-b5e6-96231b3b80d8
Canonicalize all CMake booleans to 0/1 before passing them to lit, to
ensure that the Python side handles all of them consistently
and correctly. 0/1 is a safe choice of values that trigger the same
boolean interpretation in CMake, Python and C++.
Furthermore, using them without quotes improves the chance Python will
explicitly fail when an incorrect value (such as ON/OFF, TRUE/FALSE,
YES/NO) is accidentally passed, rather than silently misinterpreting
the value.
This replaces a lot of different logics spread around lit site files,
attempting to partially reproduce the boolean logic used in CMake
and usually silently failing when an uncommon value was used instead.
In fact, some of them were never working correctly since different
values were assigned in CMake and checked in Python.
The alternative solution could be to create a common parser for CMake
booleans in lit and use it consistently throughout the site files.
However, it does not seem like the best idea to create redundant
implementation of the same logic and have to follow upstream if it ever
is extended to handle more values.
Differential Revision: https://reviews.llvm.org/D28294
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291284 91177308-0d34-0410-b5e6-96231b3b80d8
This is fixing a bug where Loop Vectorization is widening a load but
with a lower alignment. Hoisting the load without propagating the alignment
will allow inst-combine to later deduce a higher alignment that what the pointer
actually is.
Differential Revision: https://reviews.llvm.org/D28408
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291281 91177308-0d34-0410-b5e6-96231b3b80d8
