Merging r258406: ------------------------------------------------------------------------ r258406 | vedantk | 2016-01-21 09:04:42 -0800 (Thu, 21 Jan 2016) | 16 lines [GCOV] Avoid emitting profile arcs for module and skeleton CUs Do not emit profile arc files and note files for module and skeleton CU's. Our users report seeing unexpected *.gcda and *.gcno files in their projects when using gcov-style profiling with modules or frameworks. The unwanted files come from these modules. This is not very helpful for end-users. Further, we've seen reports of instrumented programs crashing while writing these files out (due to I/O failures). rdar://problem/22838296 Reviewed-by: aprantl Differential Revision: http://reviews.llvm.org/D15997 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_38@258731 91177308-0d34-0410-b5e6-96231b3b80d8
[sanitizer] [msan] Fix origin store of array types This patch fixes the memory sanitizer origin store instrumentation for array types. This can be triggered by cases where frontend lowers function return to array type instead of aggregation. For instance, the C code: -- struct mypair { int64_t x; int y; }; mypair my_make_pair(int64_t x, int y) { mypair p; p.x = x; p.y = y; return p; } int foo (int p) { mypair z = my_make_pair(p, 0); return z.y + z.x; } -- It will be lowered with target set to aarch64-linux and -O0 to: -- [...] define i32 @_Z3fooi(i32 %p) #0 { [...] %call = call [2 x i64] @_Z12my_make_pairxi(i64 %conv, i32 0) %1 = bitcast %struct.mypair* %z to [2 x i64]* store [2 x i64] %call, [2 x i64]* %1, align 8 [...] -- The origin store will emit a 'icmp' to test each store value again the TLS origin array. However since 'icmp' does not support ArrayType the memory instrumentation phase will bail out with an error. This patch change it by using the same strategy used for struct type on array. It fixes the 'test/msan/insertvalue_origin.cc' for aarch64 (the -O0 case). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@257375 91177308-0d34-0410-b5e6-96231b3b80d8
[PGO] Simplify coverage mapping lowering Coverage mapping data may reference names of functions that are skipped by FE (e.g, unused inline functions). Since those functions are skipped, normal instr-prof function lowering pass won't put those names in the right section, so special handling is needed to walk through coverage mapping structure and recollect the references. With this patch, only names that are skipped are processed. This simplifies the lowering code and it no longer needs to make assumptions coverage mapping data layout. It should also be more efficient. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@257091 91177308-0d34-0410-b5e6-96231b3b80d8
[PGO] Cleanup: remove reduncant calls in lowering CoverageMapping data's section and alignment is already set during creation. No need to call it again during lowering. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256716 91177308-0d34-0410-b5e6-96231b3b80d8
[PGO] Cleanup: Use covmap header definition in the template file This is one last remaining instrumentatation related structure that needs to be migrate to use the centralized template definition. With this change, instrumentation code related to coverage module header will be kept in sync with the coverage mapping reader. The remaining code which makes implicit assumption about covmap control structure layout in the the lowering pass will cleaned up in a different patch. This patch is not intended to have no functional change. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256715 91177308-0d34-0410-b5e6-96231b3b80d8
[safestack] Add option for non-TLS unsafe stack pointer. This patch adds an option, -safe-stack-no-tls, for using normal storage instead of thread-local storage for the unsafe stack pointer. This can be useful when SafeStack is applied to an operating system kernel. http://reviews.llvm.org/D15673 Patch by Michael LeMay. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256221 91177308-0d34-0410-b5e6-96231b3b80d8
[PGO] Fix another comdat related issue for COFF The linker requires that a comdat section must be associated with a another comdat section that precedes it. This means the comdat section's name needs to use the profile name var's name. Patch tested by Johan Engelen. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256220 91177308-0d34-0410-b5e6-96231b3b80d8
[PGO] Fix profile var comdat generation problem with COFF When targeting COFF, it is required that a comdat section to have a global obj with the same name as the comdat (except for comdats with select kind to be associative). This fix makes sure that the comdat is keyed on the data variable for COFF. Also improved test coverage for this. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256193 91177308-0d34-0410-b5e6-96231b3b80d8
[IR] Remove terminatepad It turns out that terminatepad gives little benefit over a cleanuppad which calls the termination function. This is not sufficient to implement fully generic filters but MSVC doesn't support them which makes terminatepad a little over-designed. Depends on D15478. Differential Revision: http://reviews.llvm.org/D15479 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@255522 91177308-0d34-0410-b5e6-96231b3b80d8
[sanitizer] [msan] VarArgHelper for AArch64 This patch add support for variadic argument for AArch64. All the MSAN unit tests are not passing as well the signal_stress_test (currently set as XFAIl for aarch64). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@255495 91177308-0d34-0410-b5e6-96231b3b80d8
[PGO] Stop using invalid char in instr variable names. Before the patch, -fprofile-instr-generate compile will fail if no integrated-as is specified when the file contains any static functions (the -S output is also invalid). This is the second try. The fix in this patch is very localized. Only profile symbol names of profile symbols with internal linkage are fixed up while initializer of name syms are not changes. This means there is no format change nor version bump. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@255434 91177308-0d34-0410-b5e6-96231b3b80d8
[IR] Reformulate LLVM's EH funclet IR While we have successfully implemented a funclet-oriented EH scheme on top of LLVM IR, our scheme has some notable deficiencies: - catchendpad and cleanupendpad are necessary in the current design but they are difficult to explain to others, even to seasoned LLVM experts. - catchendpad and cleanupendpad are optimization barriers. They cannot be split and force all potentially throwing call-sites to be invokes. This has a noticable effect on the quality of our code generation. - catchpad, while similar in some aspects to invoke, is fairly awkward. It is unsplittable, starts a funclet, and has control flow to other funclets. - The nesting relationship between funclets is currently a property of control flow edges. Because of this, we are forced to carefully analyze the flow graph to see if there might potentially exist illegal nesting among funclets. While we have logic to clone funclets when they are illegally nested, it would be nicer if we had a representation which forbade them upfront. Let's clean this up a bit by doing the following: - Instead, make catchpad more like cleanuppad and landingpad: no control flow, just a bunch of simple operands; catchpad would be splittable. - Introduce catchswitch, a control flow instruction designed to model the constraints of funclet oriented EH. - Make funclet scoping explicit by having funclet instructions consume the token produced by the funclet which contains them. - Remove catchendpad and cleanupendpad. Their presence can be inferred implicitly using coloring information. N.B. The state numbering code for the CLR has been updated but the veracity of it's output cannot be spoken for. An expert should take a look to make sure the results are reasonable. Reviewers: rnk, JosephTremoulet, andrew.w.kaylor Differential Revision: http://reviews.llvm.org/D15139 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@255422 91177308-0d34-0410-b5e6-96231b3b80d8
[PGO] Resubmit "MST based PGO instrumentation infrastructure" (r254021) This new patch fixes a few bugs that exposed in last submit. It also improves the test cases. --Original Commit Message-- This patch implements a minimum spanning tree (MST) based instrumentation for PGO. The use of MST guarantees minimum number of CFG edges getting instrumented. An addition optimization is to instrument the less executed edges to further reduce the instrumentation overhead. The patch contains both the instrumentation and the use of the profile to set the branch weights. Differential Revision: http://reviews.llvm.org/D12781 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@255132 91177308-0d34-0410-b5e6-96231b3b80d8
[ASAN] Add doFinalization to reset state Summary: If the same pass manager is used for multiple modules ASAN complains about GlobalsMD being initialized twice. Fix this by resetting GlobalsMD in a new doFinalization method to allow this use case. Reviewers: kcc Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D14962 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254851 91177308-0d34-0410-b5e6-96231b3b80d8
[asan] Fix dynamic allocas unpoisoning on PowerPC64. For PowerPC64 we cannot just pass SP extracted from @llvm.stackrestore to _asan_allocas_unpoison due to specific ABI requirements (http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html#DYNAM-STACK). This patch adds the value returned by @llvm.get.dynamic.area.offset to extracted from @llvm.stackrestore stack pointer, so dynamic allocas unpoisoning stuff would work correctly on PowerPC64. Patch by Max Ostapenko. Differential Revision: http://reviews.llvm.org/D15108 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254707 91177308-0d34-0410-b5e6-96231b3b80d8
[sanitizer coverage] when adding a bb trace instrumentation, do it instead, not in addition to, regular coverage. Do the regular coverage in the run-time instead git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254482 91177308-0d34-0410-b5e6-96231b3b80d8