The test expects to see the pattern "load add store" twice
in a row.
However the test contains actually several instances of this pattern.
Currently the first pattern appears in the output twice.
But after LLVM change https://reviews.llvm.org/D42691 some addtional
modification is done and one of another pattern has been hoisted in
function entry block.
As a result we have another order of meeting this pattern.
The test is updated to meet this change.
llvm-svn: 324571
This includes a few nice bits of refactoring (e.g splitting out the
exclusive locking code into a common utility).
Hopefully the Windows support is fixed now.
Patch by Rainer Orth!
Differential Revision: https://reviews.llvm.org/D40944
llvm-svn: 320731
This includes a few nice bits of refactoring (e.g splitting out the
exclusive locking code into a common utility).
Patch by Rainer Orth!
Differential Revision: https://reviews.llvm.org/D40944
llvm-svn: 320726
Summary:
As discussed in https://github.com/google/oss-fuzz/issues/933,
it would be really awesome to be able to use ThinLTO for fuzzing.
However, as @kcc has pointed out, it is currently undefined (untested)
whether the sanitizers actually function properly with LLD and/or LTO.
This patch is inspired by the cfi test, which already do test with LTO
(and/or LLD), since LTO is required for CFI to function.
I started with UBSan, because it's cmakelists / lit.* files appeared
to be the cleanest. This patch adds the infrastructure to easily add
LLD and/or LTO sub-variants of the existing lit test configurations.
Also, this patch adds the LLD flavor, that explicitly does use LLD to link.
The check-ubsan does pass on my machine. And to minimize the [initial]
potential buildbot breakage i have put some restrictions on this flavour.
Please review carefully, i have not worked with lit/sanitizer tests before.
The original attempt, r319525 was reverted in r319526 due
to the failures in compiler-rt standalone builds.
Reviewers: eugenis, vitalybuka
Reviewed By: eugenis
Subscribers: #sanitizers, pcc, kubamracek, mgorny, llvm-commits, mehdi_amini, inglorion, kcc
Differential Revision: https://reviews.llvm.org/D39508
llvm-svn: 319575
This is a resubmission of r313270. It broke standalone builds of
compiler-rt because we were not correctly generating the llvm-lit
script in the standalone build directory.
The fixes incorporated here attempt to find llvm/utils/llvm-lit
from the source tree returned by llvm-config. If present, it
will generate llvm-lit into the output directory. Regardless,
the user can specify -DLLVM_EXTERNAL_LIT to point to a specific
lit.py on their file system. This supports the use case of
someone installing lit via a package manager. If it cannot find
a source tree, and -DLLVM_EXTERNAL_LIT is either unspecified or
invalid, then we print a warning that tests will not be able
to run.
Differential Revision: https://reviews.llvm.org/D37756
llvm-svn: 313407
This patch is still breaking several multi-stage compiler-rt bots.
I already know what the fix is, but I want to get the bots green
for now and then try re-applying in the morning.
llvm-svn: 313335
This patch simplifies LLVM's lit infrastructure by enforcing an ordering
that a site config is always run before a source-tree config.
A significant amount of the complexity from lit config files arises from
the fact that inside of a source-tree config file, we don't yet know if
the site config has been run. However it is *always* required to run
a site config first, because it passes various variables down through
CMake that the main config depends on. As a result, every config
file has to do a bunch of magic to try to reverse-engineer the location
of the site config file if they detect (heuristically) that the site
config file has not yet been run.
This patch solves the problem by emitting a mapping from source tree
config file to binary tree site config file in llvm-lit.py. Then, during
discovery when we find a config file, we check to see if we have a
target mapping for it, and if so we use that instead.
This mechanism is generic enough that it does not affect external users
of lit. They will just not have a config mapping defined, and everything
will work as normal.
On the other hand, for us it allows us to make many simplifications:
* We are guaranteed that a site config will be executed first
* Inside of a main config, we no longer have to assume that attributes
might not be present and use getattr everywhere.
* We no longer have to pass parameters such as --param llvm_site_config=<path>
on the command line.
* It is future-proof, meaning you don't have to edit llvm-lit.in to add
support for new projects.
* All of the duplicated logic of trying various fallback mechanisms of
finding a site config from the main config are now gone.
One potentially noteworthy thing that was required to implement this
change is that whereas the ninja check targets previously used the first
method to spawn lit, they now use the second. In particular, you can no
longer run lit.py against the source tree while specifying the various
`foo_site_config=<path>` parameters. Instead, you need to run
llvm-lit.py.
Differential Revision: https://reviews.llvm.org/D37756
llvm-svn: 313270
Users can specify the path a raw profile is written to by passing
-fprofile-instr-generate=<path>, but this functionality broke on Darwin
after __llvm_profile_filename was made weak [1], resulting in profiles
being written to "default.profraw" even when <path> is specified.
The situation is that instrumented programs provide a weak definition of
__llvm_profile_filename, which conflicts with a weak redefinition
provided by the profiling runtime.
The linker appears to pick the 'winning' definition arbitrarily: on
Darwin, it usually prefers the larger definition, which is probably why
the instrprof-override-filename.c test has been passing.
The fix is to move the runtime's definition into a separate object file
within the archive. This means that the linker won't "see" the runtime's
definition unless the user program has not provided one. I couldn't
think of a great way to test this other than to mimic the Darwin
failure: use -fprofile-instr-generate=<some-small-path>.
Testing: check-{clang,profile}, modified instrprof-override-filename.c.
[1] [Profile] deprecate __llvm_profile_override_default_filename
https://reviews.llvm.org/D22613https://reviews.llvm.org/D22614
Differential Revision: https://reviews.llvm.org/D34797
llvm-svn: 306710
Summary:
We found a nondeterministic behavior when doing online profile merging
for multi-process applications. The application forks a sub-process and
sub-process sets to get SIGKILL when the parent process exits,
The first process gets the lock, and dumps the profile. The second one
will mmap the file, do the merge and write out the file. Note that before
the merged write, we truncate the profile.
Depending on the timing, the child process might be terminated
abnormally when the parent exits first. If this happens:
(1) before the truncation, we will get the profile for the main process
(2) after the truncation, and before write-out the profile, we will get
0 size profile.
(3) after the merged write, we get merged profile.
This patch temporarily suspend the SIGKILL for PR_SET_PDEATHSIG
before profile-write and restore it after the write.
This patch only applies to Linux system.
Reviewers: davidxl
Reviewed By: davidxl
Subscribers: xur, llvm-commits
Differential Revision: https://reviews.llvm.org/D29954
llvm-svn: 295364
Summary:
The build system was inconsistent in its naming conventions for
link flags. This patch changes all uses of LINKFLAGS to LINK_FLAGS,
for consistency with cmake's LINK_FLAGS property.
This patch should make it easier to search the source code for
uses of link flags, as well as providing the benefit of improved
style and consistency.
Reviewers: compnerd, beanz
Subscribers: kubabrecka, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D28506
llvm-svn: 291539
The Clang driver on macOS decides the deployment target based on various things, like your host OS version, the SDK version and some environment variables, which makes lit tests pass or fail based on your environment. Let's make sure we run all lit tests with `-mmacosx-version-min=${SANITIZER_MIN_OSX_VERSION}` (10.9 unless overriden).
Differential Revision: https://reviews.llvm.org/D26929
llvm-svn: 288186
This makes __llvm_profile_set_filename() work across dylib boundaries on
Darwin.
This functionality was originally meant to work on all platforms, but
was moved to a Linux-only directory with r272404. The root cause of the
test failure on Darwin was that lprofCurFilename was not marked weak.
Each dylib maintained its own copy of the variable due to the two-level
namespace.
Tested with check-profile (on Darwin). I don't expect this to regress
other platforms.
Differential Revision: https://reviews.llvm.org/D25707
llvm-svn: 284440
Profile-aarch64 :: Linux/comdat_rename.test
Profile-aarch64 :: Linux/extern_template.test
Profile-aarch64 :: Linux/instrprof-comdat.test
Profile-aarch64 :: Linux/instrprof-cs.c
The issue is that the created (aarch64) binaries were attempting to run natively
instead of running through %run, which guarantees running in the proper
environment if the compilation was configured correctly.
llvm-svn: 282264
Another CFG optimisation patch (280364) has broken bad profile tests, and this
is a similar attempt to fix the test without changing the semantics.
llvm-svn: 280373
Commit r280364 has introduced some call-graph optmisations making a profiler
test "fail" due to not expecting the compiler to be "smart", and fold constants
across functions. This commit works around the issue, leaving the origial
semantics intact.
llvm-svn: 280365
The API is intended to be used by user to do fine
grained (per-region) control of profile dumping.
Differential Revision: http://reviews.llvm.org/D23106
llvm-svn: 278092
Serguei Katkov