Currently the store+load is folded and both operands of the umulo
end up being constants. To avoid this getting folded away entirely,
make sure at least one operand is non-constant.
Also remove some allocas which don't seem relevant to the test.
llvm-svn: 355776
Adjust the XFAIL-ing tests to match consistent results from buildbot.
I'm going to work on differences between them and my local results
following this.
llvm-svn: 355774
This patch adds proper handling of -target-abi, as accepted by llvm-mc and
llc. Lowering (codegen) for the hard-float ABIs will follow in a subsequent
patch. However, this patch does add MC layer support for the hard float and
RVE ABIs (emission of the appropriate ELF flags
https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md#-file-header).
ABI parsing must be shared between codegen and the MC layer, so we add
computeTargetABI to RISCVUtils. A warning will be printed if an invalid or
unrecognized ABI is given.
Differential Revision: https://reviews.llvm.org/D59023
llvm-svn: 355771
Summary:
Uses the named operands tablegen feature to look up the indices of
offset, address, and p2align operands for all load and store
instructions. This replaces brittle, incorrect logic for identifying
loads and store when eliminating frame indices, which previously
crashed on bulk-memory ops. It also cleans up the SetP2Alignment pass.
Reviewers: aheejin, dschuff
Subscribers: sbc100, jgravelle-google, hiraditya, sunfish, jfb, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D59007
llvm-svn: 355770
This saves needing to call getInt32 ourselves. Making the code a little shorter.
The test changes are because insert/extract use getInt64 internally. Shouldn't be a functional issue.
This cleanup because I plan to write similar code for expandload/compressstore.
llvm-svn: 355767
The code commited in r355764 didn't do what I want as I typed GetThreadID
instead of GetQueueID. This commit contains a (hopefully) better version
of the workaround.
llvm-svn: 355766
When installing runtimes with install-runtimes-stripped, we don't want
to just strip them, we also want to preserve the debugging information
for potential debugging. To make it possible to later find the stripped
debugging information, we want to use the .build-id layout:
https://fedoraproject.org/wiki/RolandMcGrath/BuildID#Find_files_by_build_ID
That is, for libfoo.so with build ID abcdef1234, the debugging information
will be installed into lib/debug/.build-id/ab/cdef1234. llvm-objcopy
already has support for stripping files and linking the debugging
stripped output into the right location. However, CMake doesn't support
customizing strip invocation for the *-stripped targets. So instead, we
replace CMAKE_STRIP with a custom script that invokes llvm-objcopy with
the right command line flags.
Differential Revision: https://reviews.llvm.org/D59127
llvm-svn: 355765
This is not a fix, but if I understand enough of the issue, it should
bail out early of the test when in a situation that would result in
a failure down the road.
llvm-svn: 355764
Patch by Arthur O'Dwyer.
Reviewed as https://reviews.llvm.org/D47344
new_delete_resource().allocate(n, a) has basically two permissible results:
* Return an appropriately sized and aligned block.
* Throw bad_alloc.
Before this patch, libc++'s new_delete_resource would do a third and impermissible thing, which was
to return an appropriately sized but inappropriately under-aligned block. This is now fixed.
(This came up while I was stress-testing unsynchronized_pool_resource on my MacBook. If we can't
trust the default resource to return appropriately aligned blocks, pretty much everything breaks.
For similar reasons, I would strongly support just patching __libcpp_allocate directly, but I don't
care to die on that hill, so I made this patch as a <memory_resource>-specific workaround.)
llvm-svn: 355763
Inspired by Zachary's mail on lldb-dev, this seemed like low hanging
fruit. This patch breaks the circular dependency between commands and
expression.
Differential revision: https://reviews.llvm.org/D59158
llvm-svn: 355762
to do "databuffer + offset" so that we don't overflow the uint64_t's
we're using for addresses when working with high addresses.
Found with clang's ubsan while doing darwin kernel debugging.
<rdar://problem/48728940>
llvm-svn: 355761
When dllimport is specified on a class, and
exclude_from_explicit_instatiation is specified on a member, clang-cl
will still expect a definition to be available externally. But this is
not correct.
Surprisingly one one symbol seems to be consistently affected by this
bug. So this patch simply works around it there.
llvm-svn: 355760
This reverts commit r355764.
CMake does not turn -fPIC on for us by default. so this patch breaks
standalone builds. The only reason it hasn't broken any bots is because
LLVM turns on and specifies '-fPIC' for us.
llvm-svn: 355756
Summary:
We need to pin the underlying type of C++20' `std::memory_order` to match the C++17 version. Anything less is an ABI break.
At the moment it's `unsigned` before C++20 and `int` after. Or if you're using `-fshort-enums` it's `unsigned char` before C++20 and `int` after.
This patch explicitly specifies the underlying type of the C++20 `memory_order` to be w/e type the compiler would have chosen for the C++17 version.
Reviewers: mclow.lists, ldionne
Reviewed By: ldionne
Subscribers: jfb, jdoerfert, #libc, zoecarver
Differential Revision: https://reviews.llvm.org/D59063
llvm-svn: 355755
There are special cases in the scalarization for constant masks. If we hit one of the special cases we don't need to reset the iteration.
Noticed while starting work on adding expandload/compressstore to this pass.
llvm-svn: 355754
Summary:
Floating-point CSRs should be accessible even when F extension is not enabled.
But pseudo instructions that access floating point CSRs still require the F extension.
GNU tools already implement this behavior. RISC-V spec is pending update to reflect
this behavior and to extend it to pseudo instructions that access floating point CSRs.
Reviewers: asb
Reviewed By: asb
Subscribers: asb, rbar, johnrusso, simoncook, sabuasal, niosHD, kito-cheng, shiva0217, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, llvm-commits
Differential Revision: https://reviews.llvm.org/D58932
llvm-svn: 355753
comparator for std::sort()
Our debug comparator assumed that the comparator it wraps would always
accepts the values by const ref. This isn't required by the standard.
This patch makes our __debug_less comparator forward the constness.
llvm-svn: 355752
r44412 fixed a huge compile time regression but it needed ModifiedDT flag to be
maintained correctly in optimizations in optimizeBlock() and optimizeInst().
Function optimizeSelectInst() does not update the flag.
This patch propagates the flag in optimizeSelectInst() back to
optimizeBlock().
This patch also removes ModifiedDT in CodeGenPrepare class (which is not used).
The property of ModifiedDT is now recorded in a ref parameter.
Differential Revision: https://reviews.llvm.org/D59139
llvm-svn: 355751
This unit test fails if 'zed' appears in your build path, as lld is
echoing out the path of the source file. Change the unit test to
explicitly only match everything after the 'Symbols [' line of the
output, to make sure that this test doesn't inadvertently fail due to
the build path.
llvm-svn: 355748
Fix the NetBSD core test not to verify libc function names in backtrace.
This obviously requires the same libc.so as originally used to produce
the core file, and so it is going to fail everywhere except on my
system.
llvm-svn: 355747
Summary:
Whether we build with -fPIC should be specified by the
CMAKE_POSITION_INDEPENDENT_CODE option at configure time.
Note that this patch doesn't change the behavior when building
by default, since -fPIC is used for shared libraries by default.
Reviewers: EricWF
Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D59146
llvm-svn: 355746
Summary:
The following code is accepted by Clang 7 and prior but rejected by the upcoming 8 release and in trunk [1]
```
// error {{never produces a constant expression}}
void foo(const char* s) __attribute__((enable_if(__builtin_constant_p(*s) == false, "trap"))) {}
void test() { foo("abc"); }
```
Prior to Clang 8, the call to `__builtin_constant_p` was a constant expression returning false. Currently, it's not a valid constant expression.
The bug is caused because we failed to set `InConstantContext` when attempting to evaluate unevaluated constant expressions.
[1] https://godbolt.org/z/ksAjmq
Reviewers: rsmith, hans, sbenza
Reviewed By: rsmith
Subscribers: kristina, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D59038
llvm-svn: 355743
Specifically, compute and Print Type and Section columns.
This is a re-commit of rL354833, after fixing the Asan problem found a a buildbot.
Differential Revision: https://reviews.llvm.org/D59060
llvm-svn: 355742
An extension of D58282 noted in PR39665:
https://bugs.llvm.org/show_bug.cgi?id=39665
This doesn't answer the request to use movmsk, but that's an
independent problem. We need this and probably still need
scalarization of FP selects because we can't do that as a
target-independent transform (although it seems likely that
targets besides x86 should have this transform).
llvm-svn: 355741
Summary:
This patch works around the bug in the ptxas tool with the processing of bytes
separated by the comma symbol. The emission of the packed string is
temporarily disabled.
Reviewers: tra
Subscribers: jholewinski, jdoerfert, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D59148
llvm-svn: 355740
Summary:
This change change the instrumentation to allow users to view the registers at the point at which tag mismatch occured. Most of the heavy lifting is done in the runtime library, where we save the registers to the stack and emit unwind information. This allows us to reduce the overhead, as very little additional work needs to be done in each __hwasan_check instance.
In this implementation, the fast path of __hwasan_check is unmodified. There are an additional 4 instructions (16B) emitted in the slow path in every __hwasan_check instance. This may increase binary size somewhat, but as most of the work is done in the runtime library, it's manageable.
The failure trace now contains a list of registers at the point of which the failure occured, in a format similar to that of Android's tombstones. It currently has the following format:
Registers where the failure occurred (pc 0x0055555561b4):
x0 0000000000000014 x1 0000007ffffff6c0 x2 1100007ffffff6d0 x3 12000056ffffe025
x4 0000007fff800000 x5 0000000000000014 x6 0000007fff800000 x7 0000000000000001
x8 12000056ffffe020 x9 0200007700000000 x10 0200007700000000 x11 0000000000000000
x12 0000007fffffdde0 x13 0000000000000000 x14 02b65b01f7a97490 x15 0000000000000000
x16 0000007fb77376b8 x17 0000000000000012 x18 0000007fb7ed6000 x19 0000005555556078
x20 0000007ffffff768 x21 0000007ffffff778 x22 0000000000000001 x23 0000000000000000
x24 0000000000000000 x25 0000000000000000 x26 0000000000000000 x27 0000000000000000
x28 0000000000000000 x29 0000007ffffff6f0 x30 00000055555561b4
... and prints after the dump of memory tags around the buggy address.
Every register is saved exactly as it was at the point where the tag mismatch occurs, with the exception of x16/x17. These registers are used in the tag mismatch calculation as scratch registers during __hwasan_check, and cannot be saved without affecting the fast path. As these registers are designated as scratch registers for linking, there should be no important information in them that could aid in debugging.
Reviewers: pcc, eugenis
Reviewed By: pcc, eugenis
Subscribers: srhines, kubamracek, mgorny, javed.absar, krytarowski, kristof.beyls, hiraditya, jdoerfert, llvm-commits, #sanitizers
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D58857
llvm-svn: 355738
This matches the ELF does. Update the comment in ELF/Symbols.h and
duplicate it in wasm/Symbols.h
This a followup on rL355580 and rL355577.
Differential Revision: https://reviews.llvm.org/D59075
llvm-svn: 355737
Improve the support for processing NetBSD cores. Fix reading process
identifier, thread information and associating the terminating signal
with the correct thread.
Includes test cases for single-threaded program receiving SIGSEGV,
and two dual-threaded programs: one where thread receives the signal,
and the other one when the whole process is signalled.
Differential Revision: https://reviews.llvm.org/D32149
llvm-svn: 355736
LLVM is always built; including it in LLVM_ENABLE_PROJECTS has no
effect, but since it's in LLVM_ALL_PROJECTS, we produce a confusing
message about it being disabled. Drop it from LLVM_ALL_PROJECTS to avoid
this. Pointed out by David Greene on the mailing list [1].
[1] http://lists.llvm.org/pipermail/llvm-dev/2019-March/130854.html
llvm-svn: 355735
Commit r355068 "Fix IR/Analysis layering issue with OptBisect" uses the
template
return Gate.isEnabled() && !Gate.shouldRunPass(this, getDescription(...));
for all pass kinds. For the RegionPass, it left out the not operator,
causing region passes to be skipped as soon as a pass gate is used.
llvm-svn: 355733
When matching half of the build_vector to a load, there could still be
a hidden dependency on the other half of the build_vector the pattern
wouldn't detect. If there was an additional chain dependency on the
other value, a cycle could be introduced.
I don't think a tablegen pattern is capable of matching the necessary
conditions, so move this into PreprocessISelDAG. Check isPredecessorOf
for the other value to avoid a cycle. This has a warning that it's
expensive, so this should probably be moved into an MI pass eventually
that will have more freedom to reorder instructions to help match
this. That is currently complicated by the lack of a computeKnownBits
type mechanism for the selected function.
llvm-svn: 355731
This avoids breaking possible value dependencies when sorting loads by
offset.
AMDGPU has some load instructions that write into the high or low bits
of the destination register, and have a tied input for the other input
bits. These can easily have the same base pointer, but be a swizzle so
the high address load needs to come first. This was inserting glue
forcing the opposite ordering, producing a cycle the InstrEmitter
would assert on. It may be potentially expensive to look for the
dependency between the other loads, so just skip any where this could
happen.
Fixes bug 40936 by reverting r351379, which added a hacky attempt to
fix this by adding chains in this case, which I think was just working
around broken glue before the InstrEmitter. The core of the patch is
re-implementing the fix for that problem.
llvm-svn: 355728
Nikita Popov