We've recently changed the default for `xray_naive_log=` to be `false`
instead of `true` to make it more consistent with the FDR mode logging
implementation. This means we will now ask users to explicitly choose
which version of the XRay logging is being used.
llvm-svn: 319400
Support for outlining multiple regions of each function is added, as well as some basic heuristics to determine which regions are good to outline. Outline candidates limited to regions that are single-entry & single-exit. We also avoid outlining regions that produce live-exit variables, which may inhibit some forms of code motion (like commoning).
Fallback to the regular partial inlining scheme is retained when either i) no regions are identified for outlining in the function, or ii) the outlined function could not be inlined in any of its callers.
Differential Revision: https://reviews.llvm.org/D38190
llvm-svn: 319398
This change allows checking of function signatures but
does not yes enable it by default. In this mode, linking
two objects that were compiled with a different signatures
for the same function will produce a link error.
New options for enabling and disabling this feature have been
added: (--check-signatures/--no-check-signatures).
Differential Revision: https://reviews.llvm.org/D40371
llvm-svn: 319396
GFX9 does not enable bounds checking for the resource descriptors
used for private access, so it should be OK to use vaddr with
a potentially negative value.
llvm-svn: 319393
While the ArrayRef can technically have unaligned data, it would be
extremely surprising if iterating over it caused undefined behavior
when a reference to the underlying type was bound.
llvm-svn: 319392
This is a fix for the coverage segment builder.
If multiple regions must be popped off the active stack at once, and
more than one of them end at the same location, emit a segment using the
count from the most-recent completed region.
Fixes PR35437, rdar://35760630
Testing: invoked llvm-cov on a stage2 build of clang, additional unit
tests, check-profile
llvm-svn: 319391
Summary:
The -fxray-always-emit-customevents flag instructs clang to always emit
the LLVM IR for calls to the `__xray_customevent(...)` built-in
function. The default behaviour currently respects whether the function
has an `[[clang::xray_never_instrument]]` attribute, and thus not lower
the appropriate IR code for the custom event built-in.
This change allows users calling through to the
`__xray_customevent(...)` built-in to always see those calls lowered to
the corresponding LLVM IR to lay down instrumentation points for these
custom event calls.
Using this flag enables us to emit even just the user-provided custom
events even while never instrumenting the start/end of the function
where they appear. This is useful in cases where "phase markers" using
__xray_customevent(...) can have very few instructions, must never be
instrumented when entered/exited.
Reviewers: rnk, dblaikie, kpw
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D40601
llvm-svn: 319388
This matches MSVC's behaviour, and we already do it for class templates
since r270897.
Differential revision: https://reviews.llvm.org/D40621
llvm-svn: 319386
- add -ppc-reg-with-percent-prefix option to use %r3 etc as register
names
- split off logic for Darwinish verbose conditional codes into a helper
function
- be explicit about Darwin vs AIX vs GNUish assembler flavors
Based on the patch from Alexandre Yukio Yamashita
Differential Revision: https://reviews.llvm.org/D39016
llvm-svn: 319381
This change makes kmp_r_sched_t type into a union for simpler
comparisons and assignments
Patch by Terry Wilmarth
Differential Revision: https://reviews.llvm.org/D40374
llvm-svn: 319379
This class had some code that would automatically remap type
indices before hashing and serializing. The only caller of
this method was the TypeStreamMerger anyway, and the method
doesn't make general sense, and prevents making certain future
improvements to the class. So, factoring this up one level
into the TypeStreamMerger where it belongs.
llvm-svn: 319377
kmp_aligned_malloc() always returned NULL on Windows (stub library only)
that may cause Fortran application crash. With this change all memory
allocation functions were fixed to use aligned{m,re,rec}alloc() to
allocate/reallocate memory. To deallocate that memory _aligned_free() is
used in kmp_free().
Patch by Olga Malysheva
Differential Revision: https://reviews.llvm.org/D40296
llvm-svn: 319375
Added two warnings:
1) Before building the topology map check if tiles are requested but the
topo method is not hwloc;
2) After building the topology map check if tiles are requested but not
detected by the library.
Patch by Olga Malysheva
Differential Revision: https://reviews.llvm.org/D40340
llvm-svn: 319374
Emit a gap area starting after the r-paren location and ending at the
start of the body for the braces-optional statements (for, for-each,
while, etc). The count for the gap area equal to the body's count. This
extends the fix in r317758.
Fixes PR35387, rdar://35570345
Testing: stage2 coverage-enabled build of clang, check-clang
llvm-svn: 319373
Fortran array elements made default integer in OMP_GET_PLACE_PROC_IDS and
OMP_GET_PARTITION_PLACE_NUMS subroutines, otherwise call to them produces
incorrect result.
Patch by Olga Malysheva
Differential Revision: https://reviews.llvm.org/D40356
llvm-svn: 319372
std::set is pretty slow. We generally prefer llvm::StringSet if we don't
need an sorted set.
Differential Revision: https://reviews.llvm.org/D40579
llvm-svn: 319371
If we put in an assertsext/zext here, we're able to generate better truncate code using pack on pre-avx512 targets.
Similar is already done during type legalization. This is the equivalent for op legalization
Differential Revision: https://reviews.llvm.org/D40591
llvm-svn: 319368
Summary:
In cases where we can't use the .preinit_array section (as in Darwin for
example) we instead use dynamic initialisation. We know that this
alternative approach will race with the initializers of other objects at
global scope, but this is strictly better than nothing.
Reviewers: kubamracek, nglevin
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D40599
llvm-svn: 319366
On macOS, we usually don't require launching the target with DYLD_INSERT_LIBRARIES anymore. However, it is still necessary when running a target that is not instrumented (and e.g. dlopen's an instrument library later). In any case, ASan and TSan currently remove themselves from the DYLD_INSERT_LIBRARIES environment variable to avoid passing it onto children. This works well e.g. when instrumenting a shell. A problem arises when the target is a non-instrumented shim (e.g. "xcrun") that either re-execs or launches a child that is supposed to get DYLD_INSERT_LIBRARIES propagated. To support this mode, this patch introduces 'strip_env' flag that can be used to keep DYLD_INSERT_LIBRARIES untouched.
Differential Revision: https://reviews.llvm.org/D39991
llvm-svn: 319365
Fixes regression introduced by r319297. MSVC environments still use SEH
unwind opcodes but they should use the Microsoft C++ EH personality, not
the mingw one.
llvm-svn: 319363
directives.
According to the OpenMP standard, only loop control variables can be
used in linear clauses of distribute-based simd directives.
llvm-svn: 319362
It has no functionality effect.
I was concerned about the worse performance of DWARFDebugInfo::Parse this way
of allocating+destroying a CU for each iteration but I see it is now used only
by DWARFDebugInfo::Dump so that is no longer a problem.
Differential revision: https://reviews.llvm.org/D40212
llvm-svn: 319359
Adds support for "/ENTRY" and "/SUBSYSTEM" linker options in .drectve
sections. Some Mozilla binaries were using these directives and MSVC
link.exe appears to allow them. No attempt is made to reconcile these
with the options on the command line.
Patch by David Major!
Differential Revision: https://reviews.llvm.org/D39972
llvm-svn: 319356