Previously we asumed a vector reduction add is part of a loop and one of the input is a phi. But the code in SelectionDAGBuilder that sets vector reduction flag handles more cases than that. It just requires that the use chain ends in a horizontal reduction. And there are no other uses. This means it can handle unrolled reduction loops.
If the initial value of the reduction was 0, an unrolled loop would begin with a vector reduction add that has two sad inputs. Previously we would only transform one side of the add, but for this case we need to transform both sides.
I've created a lambda to reuse some of the code for both sides. And fixed the variables names to remove reference to "phi".
Differential Revision: https://reviews.llvm.org/D50817
llvm-svn: 340478
Tracking those can help to provide much better diagnostics in many cases.
In general, most of the visitor machinery should be refactored to allow
tracking the origin of arbitrary values.
rdar://36039765
Differential Revision: https://reviews.llvm.org/D51131
llvm-svn: 340475
Summary:
This CL adds support for arbitrary BUILD_VECTORS, i.e. not splats and
not consts. This is the last feature needed to properly lower v2i64
multiplies without a i64x2.mul instruction (which is not in the spec),
so i64x2.mul is removed as well.
Reviewers: aheejin, dschuff
Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D51082
Remove unnecessary condition and fix whitespace
llvm-svn: 340472
Previously we only used target triple as provided which matches the
GCC behavior, but it also means that all clients have to be consistent
in their spelling of target triples since e.g. x86_64-linux-gnu and
x86_64-unknown-linux-gnu will result in Clang driver looking at two
different paths when searching for runtime libraries.
Unfortunatelly, as it turned out many clients aren't consistent in
their spelling of target triples, e.g. many Linux distributions use
the shorter spelling but config.guess and rustc insist on using the
normalized variant which is causing issues. To avoid having to ship
multiple copies of runtimes for different triple spelling or rely on
symlinks which are not portable, we should also check the normalized
triple when constructing paths for multiarch runtimes.
Differential Revision: https://reviews.llvm.org/D50547
llvm-svn: 340471
This solves the motivating case from:
https://bugs.llvm.org/show_bug.cgi?id=38527
If we are legalizing an FP vector op that maps to 1 of the LLVM intrinsics that mimic libm calls,
but we're going to end up with scalar libcalls for that vector type anyway, then we should unroll
the vector op into scalars before widening. This avoids libcalls because we've lost the knowledge
that some of the scalar elements are undef.
Differential Revision: https://reviews.llvm.org/D50791
llvm-svn: 340469
Summary:
The `array-init-loop-expr` test is currently not testing the importing of ArrayInitLoopExprs.
This is because we import the `S` struct into the `test.cpp` context
and only do a copy-assignment in `test.cpp`, so the actual ArrayInitLoopExpr we wanted to
import is generated by clang directly in the target context. This means we actually
never test the importing of ArrayInitLoopExpr with this test, which becomes obvious
when looking at the missing test coverage for the respective VisitArrayInitLoopExpr method.
This patch moves the copy-assignment of our struct to the `S.cpp` context, which means
that `test.cpp` now actually has to import the ArrayInitLoopExpr.
Reviewers: a.sidorin, a_sidorin
Reviewed By: a_sidorin
Subscribers: a_sidorin, martong, cfe-commits
Differential Revision: https://reviews.llvm.org/D51115
llvm-svn: 340467
Summary:
`CXXNamedCastExpr` importing is already handled in the respective `VisitCXXNamedCastExpr` method.
So this code here can never be reached under normal circumstances and we might as well remove it.
This patch shouldn't change any observable behavior of the ASTImporter.
Reviewers: a.sidorin, a_sidorin
Reviewed By: a_sidorin
Subscribers: martong, cfe-commits
Differential Revision: https://reviews.llvm.org/D51110
llvm-svn: 340466
We're currently getting this behavior implicitly, since we determine if
a Def's optimization is valid based on the ID of its defining access.
This is incorrect, though I wouldn't be surprised if this was masked in
part by that we're using a WeakVH to track what Defs are optimized to.
(Not to mention that we don't move Defs super often, AFAICT). I'll
submit a patch to fix this shortly.
This also includes a minor refactor to reduce duplication a bit.
No test is included, since like said, this already happens to be our
behavior. I'll add a test for this with my fix to the other bug
mentioned above.
llvm-svn: 340461
Summary:
Builds fail because libxml/xmlreader.h isn't found. Adding the include
directory to the include list fixes the issue. This is what we already do on
non-macOS platforms in the same file.
Reviewers: clayborg, xiaobai, lanza
Reviewed By: clayborg, lanza
Subscribers: mgorny
Differential Revision: https://reviews.llvm.org/D50918
llvm-svn: 340460
Summary:
It's already allowed to prematurely release a scoped lock, now we also
allow relocking it again, possibly even in another mode.
This is the second attempt, the first had been merged as r339456 and
reverted in r339558 because it caused a crash.
Reviewers: delesley, aaron.ballman
Reviewed By: delesley, aaron.ballman
Subscribers: hokein, cfe-commits
Differential Revision: https://reviews.llvm.org/D49885
llvm-svn: 340459
The inline sequence is very long (about 70 bytes on Thumb1), so it's
not really a good idea to inline it, especially when optimizing for
size.
Differential Revision: https://reviews.llvm.org/D47917
llvm-svn: 340458
Add support for reading and writing MessagePack, a binary object serialization
format which aims to be more compact than text formats like JSON or YAML.
The specification can be found at
https://github.com/msgpack/msgpack/blob/master/spec.md
Will be used for encoding metadata in AMDGPU code objects.
Differential Revision: https://reviews.llvm.org/D44429
llvm-svn: 340457
Instead of asserting that the function doesn't have any unreachable
code, just ignore it for the purpose of computing liveness.
Differential Revision: https://reviews.llvm.org/D51070
llvm-svn: 340456
Fix bug https://bugs.llvm.org/show_bug.cgi?id=38643
In BPFAsmBackend applyFixup(), there is an assertion for FixedValue to be 0.
This may not be true, esp. for optimiation level 0.
For example, in the above bug, for the following two
static variables:
@bpf_map_lookup_elem = internal global i8* (i8*, i8*)*
inttoptr (i64 1 to i8* (i8*, i8*)*), align 8
@bpf_map_update_elem = internal global i32 (i8*, i8*, i8*, i64)*
inttoptr (i64 2 to i32 (i8*, i8*, i8*, i64)*), align 8
The static variable @bpf_map_update_elem will have a symbol
offset of 8 and a FK_SecRel_8 with FixupValue 8 will cause
the assertion if llvm is built with -DLLVM_ENABLE_ASSERTIONS=ON.
The above relocations will not exist if the program is compiled
with optimization level -O1 and above as the compiler optimizes
those static variables away. In the below error message, -O2
is suggested as this is the common practice.
Note that FixedValue = 0 in applyFixup() does exist and is valid,
e.g., for the global variable my_map in the above bug. The bpf
loader will process them properly for map_id's before loading
the program into the kernel.
The static variables, which are not optimized away by compiler,
may have FK_SecRel_8 relocation with non-zero FixedValue.
The patch removed the offending assertion and will issue
a hard error as below if the FixedValue in applyFixup()
is not 0.
$ llc -march=bpf -filetype=obj fixup.ll
LLVM ERROR: Unsupported relocation: try to compile with -O2 or above,
or check your static variable usage
Signed-off-by: Yonghong Song <yhs@fb.com>
llvm-svn: 340455
Summary:
When we don't actually have stack-allocated variables but need SP only
to support EH, we don't need to write SP back in the epilog, because we
don't bump down the stack pointer.
Reviewers: dschuff
Subscribers: jgravelle-google, sbc100, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D51114
llvm-svn: 340454
On Windows, movw+movt pairs with relocations are handled with a single
relocation that covers them both. Therefore we can't inject anything
between these instructions, otherwise the relocation (which in LLVM
only is treated as the movw instruction's relocation, while the movt
instruction's relocation is dropped) will end up bogus.
These instructions are bundled up until right before the constant
islands pass, making this effectively the only place that can split
them apart.
Differential Revision: https://reviews.llvm.org/D51032
llvm-svn: 340451
capability was given by the client
After r339738 Clangd started sending categories with each diagnostic, but that
broke the eglot client. This commit puts the categories behind a capability to
fix that breakage.
Differential Revision: https://reviews.llvm.org/D51077
llvm-svn: 340449
This avoids a potential infinite loop setting and unsetting bits in the
mask.
Reduced from a failure on the polly-aosp bot.
Differential Revision: https://reviews.llvm.org/D51066
llvm-svn: 340446
Summary:
Add MemorySSA as a dependency to LoopSimplifyCFG and preserve it.
Disabled by default until all passes preserve MemorySSA.
Reviewers: bogner, chandlerc
Subscribers: sanjoy, jlebar, Prazek, george.burgess.iv, llvm-commits
Differential Revision: https://reviews.llvm.org/D50911
llvm-svn: 340445
Summary:
Add MemorySSA as a depency to LoopInstInstSimplify and preserve it.
Disabled by default until all passes preserve MemorySSA.
Reviewers: chandlerc
Subscribers: sanjoy, jlebar, Prazek, george.burgess.iv, llvm-commits
Differential Revision: https://reviews.llvm.org/D50906
llvm-svn: 340444
There's no need to track a seperate variable for argmemonly aliasing. This falls out naturally of the modinfo union. Note that we may return earlier than we would have earlier if all arguments are explicitly readnone. The overall result doesn't change, just how we get there.
llvm-svn: 340443
Inspired by what AArch64 does for shifts, this patch attempts to replace shift amounts with neg if we can.
This is done directly as part of isel so its as late as possible to avoid breaking some BZHI patterns since those patterns need an unmasked (32-n) to be correct.
To avoid manual load folding and custom instruction selection for the negate. I've inserted new nodes in the DAG above the shift node in topological order.
Differential Revision: https://reviews.llvm.org/D48789
llvm-svn: 340441
constants by default when there is no optimization.
GCC's option -fno-keep-static-consts can be used to not emit
unused static constants.
In Clang, since default behavior does not keep unused static constants,
-fkeep-static-consts can be used to emit these if required. This could be
useful for producing identification strings like SVN identifiers
inside the object file even though the string isn't used by the program.
Differential Revision: https://reviews.llvm.org/D40925
llvm-svn: 340439
Summary:
There are several functions in the form of `has***` or `needs***` in
`WebAssemblyFrameLowering` and its `MachineFrameInfo` argument can be
obtained from `MachineFunction` so it is not necessarily has to be
passed from a caller. Also, it is more in line with other overriden
fuctions like `hasBP` or `hasReservedCallFrame`, which also take only
`MachineFunction` argument.
Reviewers: dschuff
Subscribers: sbc100, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D51116
llvm-svn: 340438
This was needed way back because we didn't properly handle that the SOURCES property of a target could have things that weren't source files to compile. Almost 2 years ago Takumi fixed that, and now CMake is throwing warnings that we should get off the old behavior.
llvm-svn: 340436
There are several places where we use CMAKE_CONFIGURATION_TYPES to determine if we are using an IDE generator and in turn decide not to generate some of the convenience targets (like all the install-* and check-llvm-* targets). This decision is made because IDEs don't always deal well with the thousands of targets LLVM can generate.
This approach does not work for Visual Studio 15's new CMake integration. Because VS15 uses a Ninja generator, it isn't a multi-configuration build, and generating all these extra targets mucks up the UI and adds little value.
With this change we still don't generate these targets by default for Visual Studio and Xcode generators, and LLVM_ENABLE_IDE becomes a switch that can be enabled on the VS15 CMake builds, to improve the IDE experience.
llvm-svn: 340435
When the key is not already in the map, the access operator[] creates an empty value and grows the map.
Resizing a map is very slow, so this needs to be avoided.
Found with csmith + asserts.
May help with
https://bugs.llvm.org/show_bug.cgi?id=25843
Patch by Tom Rix.
Differential Revision: https://reviews.llvm.org/D50780
llvm-svn: 340434
Summary:
`catch` instruction certainly has rather huge side effects and the flag
was missing. At the moment this does not change any unit tests we
currently have.
Reviewers: dschuff
Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D50919
llvm-svn: 340433
We're calling these functions quite a bit from outside of MemorySSA.cpp
now. Given that they're relatively simple one-liners, I think the style
preference is to have them inline.
llvm-svn: 340430
Craig Topper