| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 281973
|
|
|
|
| |
llvm-svn: 281972
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a port of XRay to ARM 32-bit, without Thumb support yet.
This is one of 3 commits to different repositories of XRay ARM port. The other 2 are:
https://reviews.llvm.org/D23931 (LLVM)
https://reviews.llvm.org/D23932 (Clang test)
Differential Revision: https://reviews.llvm.org/D23933
llvm-svn: 281971
|
|
|
|
|
|
|
|
| |
There is still a handful of them, so should not slow down
tsan apps. But gives assurance if we change/complicate
shadow mappings.
llvm-svn: 281970
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Enable more ignores when we start crashing.
Unwind in CHECK SIGSEGVs if happens early:
FATAL: ThreadSanitizer CHECK failed: ../projects/compiler-rt/lib/tsan/rtl/tsan_platform_posix.cc:105 "((beg)) <= ((end))" (0x8000000000, 0x4000000000)
Program received signal SIGSEGV, Segmentation fault.
__tsan::MetaMap::GetAndLock (this=0x1337c88 <__tsan::ctx_placeholder+8>, thr=thr@entry=0x7ffff7f91800, pc=pc@entry=4639488, addr=addr@entry=140737339086992, write_lock=write_lock@entry=true,
create=create@entry=true) at ../projects/compiler-rt/lib/tsan/rtl/tsan_sync.cc:208
208 u32 idx0 = *meta;
(gdb) bt
#0 __tsan::MetaMap::GetAndLock (this=0x1337c88 <__tsan::ctx_placeholder+8>, thr=thr@entry=0x7ffff7f91800, pc=pc@entry=4639488, addr=addr@entry=140737339086992, write_lock=write_lock@entry=true,
create=create@entry=true) at ../projects/compiler-rt/lib/tsan/rtl/tsan_sync.cc:208
#1 0x00000000004a965f in __tsan::MetaMap::GetOrCreateAndLock (this=<optimized out>, thr=thr@entry=0x7ffff7f91800, pc=pc@entry=4639488, addr=addr@entry=140737339086992, write_lock=write_lock@entry=true)
at ../projects/compiler-rt/lib/tsan/rtl/tsan_sync.cc:198
#2 0x00000000004a162a in __tsan::Release (thr=0x7ffff7f91800, pc=pc@entry=4639488, addr=addr@entry=140737339086992) at ../projects/compiler-rt/lib/tsan/rtl/tsan_rtl_mutex.cc:395
#3 0x000000000046cc40 in __interceptor_pthread_once (o=0x7ffff71a5890 <once_regsizes>, f=0x7ffff6f9d9c0 <init_dwarf_reg_size_table>) at ../projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:1334
#4 0x00007ffff6f9fe86 in __gthread_once (__func=0x7ffff6f9d9c0 <init_dwarf_reg_size_table>, __once=0x7ffff71a5890 <once_regsizes>) at ./gthr-default.h:699
#5 uw_init_context_1 (context=context@entry=0x7fffffffd6d0, outer_cfa=outer_cfa@entry=0x7fffffffd980, outer_ra=0x437d13 <__sanitizer::BufferedStackTrace::SlowUnwindStack(unsigned long, unsigned int)+67>)
at ../../../src/libgcc/unwind-dw2.c:1572
#6 0x00007ffff6fa06a8 in _Unwind_Backtrace (trace=0x437c30 <__sanitizer::Unwind_Trace(_Unwind_Context*, void*)>, trace_argument=0x7fffffffd980) at ../../../src/libgcc/unwind.inc:283
#7 0x0000000000437d13 in __sanitizer::BufferedStackTrace::SlowUnwindStack (this=0x7ffff6103208, pc=pc@entry=4863574, max_depth=max_depth@entry=256)
at ../projects/compiler-rt/lib/sanitizer_common/sanitizer_unwind_linux_libcdep.cc:125
#8 0x0000000000434f4a in __sanitizer::BufferedStackTrace::Unwind (this=this@entry=0x7ffff6103208, max_depth=max_depth@entry=256, pc=pc@entry=4863574, bp=bp@entry=0, context=context@entry=0x0,
stack_top=stack_top@entry=0, stack_bottom=stack_bottom@entry=0, request_fast_unwind=request_fast_unwind@entry=false) at ../projects/compiler-rt/lib/sanitizer_common/sanitizer_stacktrace_libcdep.cc:76
#9 0x00000000004a36b3 in PrintCurrentStackSlow (pc=4863574) at ../projects/compiler-rt/lib/tsan/rtl/tsan_rtl_report.cc:696
#10 __tsan::TsanCheckFailed (file=<optimized out>, line=<optimized out>, cond=<optimized out>, v1=<optimized out>, v2=<optimized out>) at ../projects/compiler-rt/lib/tsan/rtl/tsan_rtl_report.cc:44
#11 0x000000000042dfd6 in __sanitizer::CheckFailed (file=file@entry=0x4b9fd0 "../projects/compiler-rt/lib/tsan/rtl/tsan_platform_posix.cc", line=line@entry=105,
cond=cond@entry=0x4ba049 "((beg)) <= ((end))", v1=v1@entry=549755813888, v2=v2@entry=274877906944) at ../projects/compiler-rt/lib/sanitizer_common/sanitizer_termination.cc:79
#12 0x00000000004aa36c in ProtectRange (end=274877906944, beg=549755813888) at ../projects/compiler-rt/lib/tsan/rtl/tsan_platform_posix.cc:105
#13 __tsan::CheckAndProtect () at ../projects/compiler-rt/lib/tsan/rtl/tsan_platform_posix.cc:133
#14 0x00000000004a9e95 in __tsan::InitializePlatform () at ../projects/compiler-rt/lib/tsan/rtl/tsan_platform_linux.cc:280
#15 0x0000000000497e73 in __tsan::Initialize (thr=0x7ffff7f91800) at ../projects/compiler-rt/lib/tsan/rtl/tsan_rtl.cc:343
#16 0x00007ffff7dea25a in _dl_init (main_map=0x7ffff7ffe1c8, argc=1, argv=0x7fffffffdb88, env=0x7fffffffdb98) at dl-init.c:111
#17 0x00007ffff7ddb30a in _dl_start_user () at rtld.c:871
llvm-svn: 281969
|
|
|
|
|
|
|
| |
We were already not creating them, and with this other parts of the
code don't have to worry about them.
llvm-svn: 281968
|
|
|
|
| |
llvm-svn: 281967
|
|
|
|
|
|
|
|
| |
The generated code is still not optimal.
Differential Revision: https://reviews.llvm.org/D24723
llvm-svn: 281966
|
|
|
|
|
|
| |
Differential revision: https://reviews.llvm.org/D24664
llvm-svn: 281965
|
|
|
|
|
|
|
|
|
|
| |
The routines llvm::ConvertDebugDeclareToDebugValue() always returned
a true value which was never checked at the call site; change the
function return type to void.
This NFC cleanup was approved in the review https://reviews.llvm.org/D23715
llvm-svn: 281964
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Add links to ISA manuals and ABI.
Add text about assembler syntax.
Add info about instructions operands.
Add instruction examples for each encoding.
Update directives section, add missing .amdgpu_hsa_kernel.
Reviewers: tstellarAMD, SamWot, vpykhtin
Subscribers: kzhuravl, wdng, nhaehnle, yaxunl, tony-tye, artem.tamazov, llvm-commits
Differential Revision: https://reviews.llvm.org/D24724
llvm-svn: 281962
|
|
|
|
| |
llvm-svn: 281961
|
|
|
|
|
|
|
|
|
|
|
|
| |
SROA doesn't preserve the llvm.mem.parallel_loop_access metadata when it
transforms loads/stores. This patch fixes a couple occurences of this
issue.
(Partially addresses PR28981).
Differential Revision: https://reviews.llvm.org/D23549
llvm-svn: 281960
|
|
|
|
|
|
|
|
| |
XMM16-XMM31 or YMM16-YMM31 are the source or dest of the copy and VLX is not supported.
This can happen with SUBREG_TO_REG of ZMM16-ZMM31. Fixes PR30430.
llvm-svn: 281959
|
|
|
|
|
|
|
|
| |
when F16C and VLX are not supported.
Fixes PR23941.
llvm-svn: 281958
|
|
|
|
|
|
|
|
|
|
| |
It is legal to merge instructions with different undef flags; However we
must drop the undef flag from the merged instruction if it isn't present
everywhere.
This fixes http://llvm.org/PR30199
llvm-svn: 281957
|
|
|
|
| |
llvm-svn: 281956
|
|
|
|
|
|
|
|
|
|
|
| |
Use SmallVector instead of dynamically allocated arrays for the mapping of the
operands in the InstructionMapping. That way we avoid heap allocation for most
of the cases. Ultimately, we should not have to rely on such tricky, the
instances of InstructionMapping would be TableGen'ed.
This improves the compilation time of the RegBankSelect pass.
llvm-svn: 281955
|
|
|
|
|
| |
FIXME: It seems clangFormat is not referred.
llvm-svn: 281954
|
|
|
|
| |
llvm-svn: 281953
|
|
|
|
| |
llvm-svn: 281952
|
|
|
|
| |
llvm-svn: 281951
|
|
|
|
| |
llvm-svn: 281950
|
|
|
|
|
|
|
|
|
|
| |
When looking at the scribus_1.3 example from https://llvm.org/bugs/show_bug.cgi?id=10584, I noticed that we were spending a large amount of time computing loop exits in LCSSA. This code appears to be written with the assumption that LoopExits are stored in the Loop and thus cheap to query. This is not true, so we should cache the result across the potentially long running loop which tends to visit a small handful of Loops.
On the particular example from 10584, this change drops the time spent in LCSSA computation by about 80%.
Differential Revision: https://reviews.llvm.org/D24509
llvm-svn: 281949
|
|
|
|
|
|
| |
This was meant to be commited with my previous commit.
llvm-svn: 281948
|
|
|
|
| |
llvm-svn: 281947
|
|
|
|
|
|
|
|
|
|
| |
InputSection<ELFT>::Discarded has no name and it's not backed by
a file. Trying to report it as discared will cause a nullptr
dereference, therefore a crash. Skip it.
Differential Revision: https://reviews.llvm.org/D24731
llvm-svn: 281946
|
|
|
|
|
|
|
| |
This essentially reverts r251936, minimizing the difference between Chapter2
and Chapter 3, and making Chapter 2's code match the tutorial text.
llvm-svn: 281945
|
|
|
|
| |
llvm-svn: 281944
|
|
|
|
| |
llvm-svn: 281943
|
|
|
|
|
|
|
|
| |
This converts Args::Unshift, Args::AddOrReplaceEnvironmentVariable,
and Args::ContainsEnvironmentVariable to use StringRefs. The code
is also simplified somewhat as a result.
llvm-svn: 281942
|
|
|
|
|
|
| |
included in armv8.1-a by default and so we weren't testing anything.
llvm-svn: 281941
|
|
|
|
|
|
| |
operand bundles
llvm-svn: 281940
|
|
|
|
|
|
|
|
|
|
|
| |
The comments of SplitBlockAndInsertIfThenElse say the SplitBefore instruction will stay in the old block.
But according to the implementation(split the block at SplitBefore by using splitBasicBlock), the SplitBefore will be moved to the new block.
This patch fixes the comments.
Patch by Zhe Yu Wu.
llvm-svn: 281939
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The Sanitizer Secondary Allocator was not entirely ideal was Scudo for several
reasons: decent amount of unneeded code, redundant checks already performed by
the front end, unneeded data structures, difficulty to properly protect the
secondary chunks header.
Given that the second allocator is pretty straight forward, Scudo will use its
own, trimming all the unneeded code off of the Sanitizer one. A significant
difference in terms of security is that now each secondary chunk is preceded
and followed by a guard page, thus mitigating overflows into and from the
chunk.
A test was added as well to illustrate the overflow & underflow situations
into the guard pages.
Reviewers: kcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D24737
llvm-svn: 281938
|
|
|
|
|
|
| |
Renamed and added v2i64 / v4i64 tests
llvm-svn: 281937
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
These functions take and return wint_t, not int:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/towupper.html
Reviewers: mclow.lists, EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D24743
llvm-svn: 281936
|
|
|
|
| |
llvm-svn: 281935
|
|
|
|
|
|
|
|
|
|
|
| |
ArrayBoundChecker did not detect out of bounds memory access errors in case an
array was allocated by the new expression. This patch resolves this issue.
Patch by Daniel Krupp!
Differential Revision: https://reviews.llvm.org/D24307
llvm-svn: 281934
|
|
|
|
|
|
| |
coverage from instrumented libc++
llvm-svn: 281933
|
|
|
|
| |
llvm-svn: 281932
|
|
|
|
|
|
|
| |
An input section named .data.rel.ro now maps to an output section
named .data.rel.ro. Before we were mapping it to .data.
llvm-svn: 281931
|
|
|
|
|
|
|
| |
By making every section on byte and checking the size it now shows how
many sections were concatenated into each output section.
llvm-svn: 281930
|
|
|
|
|
|
|
| |
That is not what this test is about. This reduces changes in another
patch that changes layout.
llvm-svn: 281929
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Callsites in the same basic block should share the same hotness. This patch checks for the hottest callsite in the same basic block, and use the hotness for all callsites in that basic block for early inline decisions. It also fixes the test to add "-S" so theat the "CHECK-NOT" is actually checking the content.
Reviewers: dnovillo
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D24734
llvm-svn: 281927
|
|
|
|
| |
llvm-svn: 281926
|
|
|
|
|
|
|
|
|
|
| |
On Windows, marking an `extern template class` declaration as exported
actually forces an instantiation, which is not the desired behavior.
Instead, the actual explicit instantiations need to be exported.
Differential Revision: https://reviews.llvm.org/D24679
llvm-svn: 281925
|
|
|
|
| |
llvm-svn: 281923
|
|
|
|
| |
llvm-svn: 281922
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
None of these checks are specific to Android devices. If libc++ was
used with Bionic on a normal Linux system these checks would still be
needed.
Reviewers: mclow.lists, EricWF
Subscribers: compnerd, tberghammer, danalbert, srhines, cfe-commits
Differential Revision: https://reviews.llvm.org/D24690
llvm-svn: 281921
|