Instantiation of the MachineVerifierPass through
PassInfo::getNormalCtor would yield a segfault since the default
constructor of the MachineVerifierPass takes a reference to nullptr.
Patch by Simone Pellegrini.
Differential Revision: https://reviews.llvm.org/D31387
llvm-svn: 298987
This will result in a KMOVW or KMOVD being emitted during register allocation. And in at least some cases this might allow the register coalescer to remove the copy all together.
llvm-svn: 298984
Summary:
It is problematic for this reader that it expects to read data from
several threads, but the header or message format does not define
framing. Since the buffers are reused, we can't rely on skipping
zeroed out data as a synchronization method either.
There is an argument that this is not version compatible with the format
the reader expected previously. I argue that since the writer wrote garbage
past the end of buffer record, there is no currently working reader to
compromise.
The corresponding writer change is posted to D31384.
Reviewers: dberris, pelikan
Reviewed By: dberris
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31385
llvm-svn: 298983
Summary:
Currently the FDR log writer, upon flushing, dumps a sequence of buffers from
its freelist to disk. A reader can read the first buffer up to an EOB record,
but then it is unclear how far ahead to scan to find the next threads traces.
There are a few ways to handle this problem.
1. The reader has externalized knowledge of the buffer size.
2. The size of buffers is in the file header or otherwise encoded in the log.
3. Only write out the portion of the buffer with records. When released, the
buffers are marked with a size.
4. The reader looks for memory that matches a pattern and synchronizes on it.
2 and 3 seem the most flexible and 2 does not rule 3 out.
This is an implementation of 2.
In addition, the function handler for fdr more aggressively checks for
finalization and makes an attempt to release its buffer.
Reviewers: pelikan, dberris
Reviewed By: dberris
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31384
llvm-svn: 298982
Summary:
This change exercises the end-to-end functionality defined in the FDR
logging implementation. We also prepare for being able to run traces
generated by the FDR logging implementation from being analysed with the
llvm-xray command that comes with the LLVM distribution.
This also unblocks D31385, D31384, and D31345.
Reviewers: kpw, pelikan
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D31452
llvm-svn: 298977
Summary:
Currently the llvm-xray commandline tool fails to handle the case for
when no subcommand is provided in a graceful manner. This fixes that to
print the help message explaining the subcommands and the available
options.
Reviewers: pcc, pelikan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31409
llvm-svn: 298975
Summary:
Originally, a few tests fail for armhf target due to:
1) COMPILER_RT_ARMHF_TARGET was not set when building the lib
2) COMPILER_RT_ABI should not be defined as `__attribute__((pcs("aapcs")))` for armhf when building for both lib and tests
This address https://bugs.llvm.org//show_bug.cgi?id=32261
mulsc3_test.c is a newly exposed issue, which will be addressed separately.
Reviewers: rengolin, compnerd
Reviewed By: compnerd
Subscribers: aemerson, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D31448
llvm-svn: 298974
Properly propagate the FMF from the LLVM IR to this flag.
This is toward moving fp-contraction=fast from an LLVM TargetOption to a
FastMathFlag in order to fix PR25721.
Differential Revision: https://reviews.llvm.org/D31165
llvm-svn: 298961
We should be masking the value and emitting a register copy like we do in non-fast isel. Instead we were just updating the value map and emitting nothing.
After r298928 we started seeing cases where we would create a copy from GR8 to GR32 because the source register in a VK1 to GR32 copy was replaced by the GR8 going into a truncate.
This fixes PR32451.
llvm-svn: 298957
In PPCBoolRetToInt bool value is changed to i32 type. On ppc64 it may introduce an extra zero extension for the return value. This patch changes the integer type to i64 to avoid the zero extension on ppc64.
This patch fixed PR32442.
Differential Revision: https://reviews.llvm.org/D31407
llvm-svn: 298955
Summary:
This patch is a stripped down from features a NetBSD process
code (patch is kept under 2k LOC). This code has assumption that
there is only one thread within a debugged process. The only
debugger trap supported is software breakpoint (TRAP_BRKPT).
The generic platform code requires to add dummy function for
watchpoints etc. These functions are currently empty.
This code is not the final platform support as is and it's treated as
a base to extend, refactor and address issues afterwards.
Supported features:
- handle software breakpoints,
- correctly attach to a tracee,
- support NetBSD specific ptrace(2),
- monitor process termination,
- monitor SIGTRAP events,
- monitor SIGSTOP events,
- monitor other signals events,
- resume the whole process,
- get memory region info perms,
- read memory from tracee,
- write memory to tracee,
- read ELF AUXV,
- x86_64 GPR read and write code
For the generic framework include:
- halt,
- detach,
- signal,
- kill,
- allocatememory,
- deallocatememory,
- update threads,
- getarchitecture,
- getfileloadaddress,
- and others.
This code has preliminary AddThread code.
Out of interest in this patch:
- exec() traps,
- hardware debug register traps,
- single step trap,
- thread creation/termination trap,
- process fork(2), vfork(2) and vfork(2) done traps,
- syscall entry and exit trap,
- threads,
- FPR registers,
- retrieving tracee's thread name,
- non x86_64 support.
This code can be used to start a hello world application and trace it.
This code can be used by other BSD systems as a starting point to get similar
capabilities.
Sponsored by <The NetBSD Foundation>
Reviewers: emaste, joerg, kettenis, labath
Subscribers: mgorny, #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D31374
llvm-svn: 298953
This is less important than increase threshold for private memory,
but still brings performance improvements in a wide range of tests.
Unrolling more for local memory serves three purposes: it allows
to combine ds operations if offset becomes static, saves registers
used for offsets in case of static offsets, and allows better lds
latency hiding.
Differential Revision: https://reviews.llvm.org/D31412
llvm-svn: 298948
Summary:
This prevents InternalAlloc from being called before the sanitizers
are fully initialized.
Reviewers: kubamracek, kcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31306
llvm-svn: 298947
Summary:
Now that __thread is no longer used for lsan on darwin, i386 builds
can be enabled.
Reviewers: kcc, kubamracek
Subscribers: danalbert, srhines, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D29995
llvm-svn: 298946
This is incorrect to record region boundaries before scheduling,
it may change after scheduling. As a result second pass may see less
instructions to schedule than it should.
Differential Revision: https://reviews.llvm.org/D31434
llvm-svn: 298945
We currently perform the various fp_to_sint XMM conversion and then transfer to the MMX register (on 32-bit via the stack).
This patch improves support for MOVDQ2Q XMM to MMX transfers and adds the XMM->MMX fp_to_sint direct conversion patterns. The SSE2 specifications are the same as for XMM->XMM and XMM->MMX rounding/exceptions/etc.
Differential Revision: https://reviews.llvm.org/D30868
llvm-svn: 298943
Summary: In the ELF linker, we create the buffer identifier for bitcode files by appending the object name to the archive name. This change makes the COFF linker do the same. Without the change, ThinLTO builds can fail with an error message about multiple ThinLTO modules per object file, caused by object files contained in different archives having the same name.
Reviewers: pcc, ruiu
Reviewed By: pcc
Subscribers: mehdi_amini
Differential Revision: https://reviews.llvm.org/D31402
llvm-svn: 298942
-ffp-contract=fast does not currently work with LTO because it's passed as a
TargetOption to the backend rather than in the IR. This adds it to
FastMathFlags.
This is toward fixing PR25721
Differential Revision: https://reviews.llvm.org/D31164
llvm-svn: 298939
Simon Pilgrim