Fix for memory leak reported by Valgrind

If llvm so lib is dlopened and dlclosed several times, then memory leak can be observed, reported by Valgrind.

This patch fixes the issue.

Reviewed By: lat

Fix for memory leak reported by Valgrind

If llvm so lib is dlopened and dlclosed several times, then memory leak can be observed, reported by Valgrind.

This patch fixes the issue.

Reviewed By: lattner, dblaikie

Differential Revision: https://reviews.llvm.org/D83372

show more ...

[Support] Replace sys::Mutex with their standard equivalents.

Only use a recursive mutex if it can be locked recursively.

llvm-svn: 369295

Replace llvm::MutexGuard/UniqueLock with their standard equivalents

All supported platforms have <mutex> now, so we don't need our own
copies any longer. No functionality change intended.

llvm-svn:

Replace llvm::MutexGuard/UniqueLock with their standard equivalents

All supported platforms have <mutex> now, so we don't need our own
copies any longer. No functionality change intended.

llvm-svn: 368149

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

Remove trailing space

sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h}

llvm-svn: 338293

[NFC] Remove inaccurate comment

Summary:
r271558 moved getManagedStaticMutex's mutex from a function-local
static to using call_once, but left a comment added in r211424. That comment is
now erroneo

[NFC] Remove inaccurate comment

Summary:
r271558 moved getManagedStaticMutex's mutex from a function-local
static to using call_once, but left a comment added in r211424. That comment is
now erroneous, remove it.

Reviewers: zturner, chandlerc

Subscribers: aheejin, llvm-commits

Differential Revision: https://reviews.llvm.org/D46784

llvm-svn: 332175

show more ...

Revamp llvm::once_flag to be closer to std::once_flag

Summary:
Make this interface reusable similarly to std::call_once and std::once_flag interface.

This makes porting LLDB to NetBSD easier as the

Revamp llvm::once_flag to be closer to std::once_flag

Summary:
Make this interface reusable similarly to std::call_once and std::once_flag interface.

This makes porting LLDB to NetBSD easier as there was in the original approach a portable way to specify a non-static once_flag. With this change translating std::once_flag to llvm::once_flag is mechanical.

Sponsored by <The NetBSD Foundation>

Reviewers: mehdi_amini, labath, joerg

Reviewed By: mehdi_amini

Subscribers: emaste, clayborg

Differential Revision: https://reviews.llvm.org/D29566

llvm-svn: 294143

show more ...

[ManagedStatic] Reimplement double-checked locking with std::atomic.

This gets rid of the memory fence in the hot path (dereferencing the
ManagedStatic), trading for an extra mutex lock in the cold

[ManagedStatic] Reimplement double-checked locking with std::atomic.

This gets rid of the memory fence in the hot path (dereferencing the
ManagedStatic), trading for an extra mutex lock in the cold path (when
the ManagedStatic was uninitialized). Since this only happens on the
first accesses it shouldn't matter much. On strict architectures like
x86 this removes any atomic instructions from the hot path.

Also remove the tsan annotations, tsan knows how standard atomics work
so they should be unnecessary now.

llvm-svn: 274131

show more ...

[LPM] Reinstate r271781 which reinstated r271652 to replace the
CALL_ONCE_... macro in the legacy pass manager with the new
llvm::call_once facility.

Nothing changed sicne the last attempt in r27178

[LPM] Reinstate r271781 which reinstated r271652 to replace the
CALL_ONCE_... macro in the legacy pass manager with the new
llvm::call_once facility.

Nothing changed sicne the last attempt in r271781 which I reverted in
r271788. At least one of the failures I saw was spurious, and I want to
make sure the other failures are real before I work around them -- they
appeared to only effect ppc64le and ppc64be.

Original commit message of r271781:
----
[LPM] Reinstate r271652 to replace the CALL_ONCE_... macro in the legacy
pass manager with the new llvm::call_once facility.

This reverts commit r271657 and re-applies r271652 with a fix to
actually work with arguments. In the original version, we just ended up
directly calling std::call_once via ADL because of the std::once_flag
argument. The llvm::call_once never worked with arguments. Now,
llvm::call_once is a variadic template that perfectly forwards
everything. As a part of this it had to move to the header and we use
a generic functor rather than an explict function pointer. It would be
nice to use std::invoke here but we don't have it yet. That means
pointer to members won't work here, but that seems a tolerable
compromise.

I've also tested this by forcing the fallback path, so hopefully it
sticks this time.
----

Original commit message of r271652:
----
[LPM] Replace the CALL_ONCE_... macro in the legacy pass manager with
the new llvm::call_once facility.

This facility matches the standard APIs and when the platform supports
it actually directly uses the standard provided functionality. This is
both more efficient on some platforms and much more TSan friendly.

The only remaining user of the cas_flag and home-rolled atomics is the
fallback implementation of call_once. I have a patch that removes them
entirely, but it needs a Windows patch to land first.

This alone substantially cleans up the macros for the legacy pass
manager, and should subsume some of the work Mehdi was doing to clear
the path for TSan testing of ThinLTO, a really important step to have
reliable upstream testing of ThinLTO in all forms.
----

llvm-svn: 271800

show more ...

[LPM] Revert r271781 which was a re-commit of r271652.

There appears to be a strange exception thrown and crash using call_once
on a PPC build bot, and a *really* weird windows link error for
GCMeta

[LPM] Revert r271781 which was a re-commit of r271652.

There appears to be a strange exception thrown and crash using call_once
on a PPC build bot, and a *really* weird windows link error for
GCMetadata.obj. Still need to investigate the cause of both problems.

Original change summary:
[LPM] Reinstate r271652 to replace the CALL_ONCE_... macro in the legacy
pass manager with the new llvm::call_once facility.

llvm-svn: 271788

show more ...

[LPM] Reinstate r271652 to replace the CALL_ONCE_... macro in the legacy
pass manager with the new llvm::call_once facility.

This reverts commit r271657 and re-applies r271652 with a fix to
actually

[LPM] Reinstate r271652 to replace the CALL_ONCE_... macro in the legacy
pass manager with the new llvm::call_once facility.

This reverts commit r271657 and re-applies r271652 with a fix to
actually work with arguments. In the original version, we just ended up
directly calling std::call_once via ADL because of the std::once_flag
argument. The llvm::call_once never worked with arguments. Now,
llvm::call_once is a variadic template that perfectly forwards
everything. As a part of this it had to move to the header and we use
a generic functor rather than an explict function pointer. It would be
nice to use std::invoke here but we don't have it yet. That means
pointer to members won't work here, but that seems a tolerable
compromise.

I've also tested this by forcing the fallback path, so hopefully it
sticks this time.

Original commit message:
----
[LPM] Replace the CALL_ONCE_... macro in the legacy pass manager with
the new llvm::call_once facility.

This facility matches the standard APIs and when the platform supports
it actually directly uses the standard provided functionality. This is
both more efficient on some platforms and much more TSan friendly.

The only remaining user of the cas_flag and home-rolled atomics is the
fallback implementation of call_once. I have a patch that removes them
entirely, but it needs a Windows patch to land first.

This alone substantially cleans up the macros for the legacy pass
manager, and should subsume some of the work Mehdi was doing to clear
the path for TSan testing of ThinLTO, a really important step to have
reliable upstream testing of ThinLTO in all forms.

llvm-svn: 271781

show more ...

This is yet another attempt to re-instate r220932 as discussed in
D19271.

Previous attempt was broken by NetBSD, so in this version I've made the
fallback path generic rather than Windows specific a

This is yet another attempt to re-instate r220932 as discussed in
D19271.

Previous attempt was broken by NetBSD, so in this version I've made the
fallback path generic rather than Windows specific and sent both Windows
and NetBSD to it.

I've also re-formatted the code some, and used an exact clone of the
code in PassSupport.h for doing manual call-once using our atomics
rather than rolling a new one.

If this sticks, we can replace the fallback path for Windows with
a Windows-specific implementation that is more reliable.

Original commit message:
This patch adds an llvm_call_once which is a wrapper around
std::call_once on platforms where it is available and devoid
of bugs. The patch also migrates the ManagedStatic mutex to
be allocated using llvm_call_once.

These changes are philosophically equivalent to the changes
added in r219638, which were reverted due to a hang on Win32
which was the result of a bug in the Windows implementation
of std::call_once.

Differential Revision: http://reviews.llvm.org/D5922

llvm-svn: 271558

show more ...

Revert "Revert "Revert 220932.": "Removing the static initializer in ManagedStatic.cpp by using llvm_call_once to initialize the ManagedStatic mutex""

This reverts commit r269577.
Broke NetBSD, wait

Revert "Revert "Revert 220932.": "Removing the static initializer in ManagedStatic.cpp by using llvm_call_once to initialize the ManagedStatic mutex""

This reverts commit r269577.
Broke NetBSD, waiting for Kamil to investigate

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 269584

show more ...

Revert "Revert 220932.": "Removing the static initializer in ManagedStatic.cpp by using llvm_call_once to initialize the ManagedStatic mutex"

This reverts commit r221331 and reinstate r220932 as dis

Revert "Revert 220932.": "Removing the static initializer in ManagedStatic.cpp by using llvm_call_once to initialize the ManagedStatic mutex"

This reverts commit r221331 and reinstate r220932 as discussed in D19271.
Original commit message was:

This patch adds an llvm_call_once which is a wrapper around
std::call_once on platforms where it is available and devoid
of bugs. The patch also migrates the ManagedStatic mutex to
be allocated using llvm_call_once.

These changes are philosophically equivalent to the changes
added in r219638, which were reverted due to a hang on Win32
which was the result of a bug in the Windows implementation
of std::call_once.

Differential Revision: http://reviews.llvm.org/D5922

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 269577

show more ...

[NFC] Header cleanup

Removed some unused headers, replaced some headers with forward class declarations.

Found using simple scripts like this one:
clear && ack --cpp -l '#include "llvm/ADT/IndexedM

[NFC] Header cleanup

Removed some unused headers, replaced some headers with forward class declarations.

Found using simple scripts like this one:
clear && ack --cpp -l '#include "llvm/ADT/IndexedMap.h"' | xargs grep -L 'IndexedMap[<]' | xargs grep -n --color=auto 'IndexedMap'

Patch by Eugene Kosov <claprix@yandex.ru>

Differential Revision: http://reviews.llvm.org/D19219

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266595

show more ...

Support: Clean up TSan annotations.

Remove support for Valgrind-based TSan, which hasn't been maintained for a
few years. We now use the TSan annotations only if LLVM is compiled with
-fsanitize=thr

Support: Clean up TSan annotations.

Remove support for Valgrind-based TSan, which hasn't been maintained for a
few years. We now use the TSan annotations only if LLVM is compiled with
-fsanitize=thread. We no longer need the weak function definitions as we
are guaranteed that our program is linked directly with the TSan runtime.

Differential Revision: http://reviews.llvm.org/D12121

llvm-svn: 245374

show more ...

Revert 220932.

Commit 220932 caused crash when building clang-tblgen on aarch64 debian target,
so it's blocking all daily tests.

The std::call_once implementation in pthread has bug for aarch64 deb

Revert 220932.

Commit 220932 caused crash when building clang-tblgen on aarch64 debian target,
so it's blocking all daily tests.

The std::call_once implementation in pthread has bug for aarch64 debian.

llvm-svn: 221331

show more ...

Removing the static initializer in ManagedStatic.cpp by using llvm_call_once to initialize the ManagedStatic mutex.

Summary:
This patch adds an llvm_call_once which is a wrapper around std::call_onc

Removing the static initializer in ManagedStatic.cpp by using llvm_call_once to initialize the ManagedStatic mutex.

Summary:
This patch adds an llvm_call_once which is a wrapper around std::call_once on platforms where it is available and devoid of bugs. The patch also migrates the ManagedStatic mutex to be allocated using llvm_call_once.

These changes are philosophically equivalent to the changes added in r219638, which were reverted due to a hang on Win32 which was the result of a bug in the Windows implementation of std::call_once.

Reviewers: aaron.ballman, chapuni, chandlerc, rnk

Reviewed By: rnk

Subscribers: majnemer, llvm-commits

Differential Revision: http://reviews.llvm.org/D5922

llvm-svn: 220932

show more ...

Revert r219638, (r219640 and r219676), "Removing the static destructor from ManagedStatic.cpp by controlling the allocation and de-allocation of the mutex."

It caused hang-up on msc17 builder, proba

Revert r219638, (r219640 and r219676), "Removing the static destructor from ManagedStatic.cpp by controlling the allocation and de-allocation of the mutex."

It caused hang-up on msc17 builder, probably deadlock.

llvm-svn: 219687

show more ...

Removing the static destructor from ManagedStatic.cpp by controlling the allocation and de-allocation of the mutex.

This patch adds a new llvm_call_once function which is used by the ManagedStatic i

Removing the static destructor from ManagedStatic.cpp by controlling the allocation and de-allocation of the mutex.

This patch adds a new llvm_call_once function which is used by the ManagedStatic implementation to safely initialize a global to avoid static construction and destruction.

llvm-svn: 219638

show more ...

Fix the MinGW builder. Apparently std::call_once and
std::recursive_mutex are not available on MinGW and breaks the
builder. Revert to using a function local static and sys::Mutex
just to get the t

Fix the MinGW builder. Apparently std::call_once and
std::recursive_mutex are not available on MinGW and breaks the
builder. Revert to using a function local static and sys::Mutex
just to get the tree green until we figure out a better solution.

llvm-svn: 211424

show more ...

Remove use of removed function, llvm_stop_multithreading

llvm-svn: 211291

Kill the LLVM global lock.

This patch removes the LLVM global lock, and updates all existing
users of the global lock to use their own mutex. None of the
existing users of the global lock were pr

Kill the LLVM global lock.

This patch removes the LLVM global lock, and updates all existing
users of the global lock to use their own mutex. None of the
existing users of the global lock were protecting code that was
mutually exclusive with any of the other users of the global
lock, so its purpose was not being met.

Reviewed by: rnk

Differential Revision: http://reviews.llvm.org/D4142

llvm-svn: 211277

show more ...

Revert r211066, 211067, 211068, 211069, 211070.

These were committed accidentally from the wrong branch before having
a review sign-off.

llvm-svn: 211072

Kill the LLVM global lock.

llvm-svn: 211069