| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 340476
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
This is tested in a subsequent commit, which allows tracking those values.
Differential Revision: https://reviews.llvm.org/D51139
llvm-svn: 340474
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D51130
llvm-svn: 340473
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
around the buggy access, simplify one test
llvm-svn: 340470
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
undef elements (PR38527)
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: a.sidorin, a_sidorin
Reviewed By: a_sidorin
Subscribers: martong, cfe-commits
Differential Revision: https://reviews.llvm.org/D51121
llvm-svn: 340468
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: a.sidorin, a_sidorin
Reviewed By: a_sidorin
Subscribers: martong, cfe-commits
Differential Revision: https://reviews.llvm.org/D51059
llvm-svn: 340465
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: a.sidorin, a_sidorin
Reviewed By: a_sidorin
Subscribers: a_sidorin, martong, cfe-commits
Differential Revision: https://reviews.llvm.org/D51056
llvm-svn: 340464
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: a.sidorin, a_sidorin
Reviewed By: a_sidorin
Subscribers: martong, cfe-commits
Differential Revision: https://reviews.llvm.org/D51123
llvm-svn: 340463
|
|
|
|
| |
llvm-svn: 340462
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Already works, but I initially convinced myself it doesn't, so add a test which shows it does. :)
llvm-svn: 340453
|
|
|
|
| |
llvm-svn: 340452
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
This makes sure the flags are available for use for thumb MIR as well.
A test that requires this will be added in the next commit.
llvm-svn: 340450
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: labath, #lldb
Reviewed By: labath
Subscribers: jloser, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D50298
llvm-svn: 340448
|
|
|
|
| |
llvm-svn: 340447
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 340442
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
is masked in hardware
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
|
|
|
|
| |
llvm-svn: 340440
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
accessing
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
|
|
|
|
|
|
|
|
|
| |
uadd.with.overflow
CGP can replace a branch + select with a uadd.with.overflow. Teach it to
set debug locations as it does this.
llvm-svn: 340432
|
|
|
|
| |
llvm-svn: 340431
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
https://reviews.llvm.org/D51053
Added legalization for WidenScalar of various bitcounting opcodes.
Reviewed by arsenm.
llvm-svn: 340429
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a rebased version https://reviews.llvm.org/D42176 which is patch
by Nicolas Wilson.
Addresses issue:
https://github.com/WebAssembly/tool-conventions/issues/32, and
https://bugs.llvm.org/show_bug.cgi?id=38650
Previously, for each function/segment we iterated over every relocation
to find the relevant ones, which is an n^2 operation. Now, we just make
a single pass.
Differential Revision: https://reviews.llvm.org/D51063
llvm-svn: 340428
|
|
|
|
|
|
|
|
|
| |
It looks like this test XPASSes when the deployment target is older than
the OS of the system the test is running on. It looks like we run the
tests with -mmacosx-version-min=10.12, and that makes the test expect to
fail, but it passes.
llvm-svn: 340427
|
|
|
|
|
|
|
|
|
|
| |
These algorithms require a ForwardIterator or better. Ensure
we diagnose the contract violation at compile time instead of
of silently doing the wrong thing.
Further algorithms will be audited in upcoming patches.
llvm-svn: 340426
|