Would it be possible to trigger lazy registration if the version is read
as a zero? This would not introduce any additional atomic instructions
on the fast path.
yes, that is possible. The main problem is the transition from lazy to
non-lazy mode when the first exception is thrown. We must som
* Thomas Neumann:
> Hi,
>
> When dynamically linking a fast enough machine hides the latency, but when
> Statically linking or on slower devices this change caused a 5x increase
> in
> Instruction count and 2x increase in cycle count before getting to main.
>
> I have looked at wa
Hi,
When dynamically linking a fast enough machine hides the latency, but when
Statically linking or on slower devices this change caused a 5x increase in
Instruction count and 2x increase in cycle count before getting to main.
I have looked at ways to fix that. The problem is that with static
On Mon, Nov 21, 2022 at 3:49 AM Jakub Jelinek via Gcc-patches
wrote:
>
> On Mon, Nov 21, 2022 at 12:22:32PM +0100, Thomas Neumann via Gcc-patches
> wrote:
> > > When dynamically linking a fast enough machine hides the latency, but when
> > > Statically linking or on slower devices this change cau
It's easy to reproduce on x86 as well.
As a testcase:
#include
int main(int argc, char** argv) {
return 0;
}
And just compile with: g++ -O1 hello.cpp -static -o hello.exe.
thanks, I will take a look.
Best
Thomas
> -Original Message-
> From: Thomas Neumann
> Sent: Monday, November 21, 2022 11:23 AM
> To: Tamar Christina ; gcc-patches@gcc.gnu.org;
> Jason Merrill
> Cc: Florian Weimer ; Jakub Jelinek
> ; Jonathan Wakely
> Subject: Re: [PATCH v4] eliminate mutex in fast
On Mon, Nov 21, 2022 at 12:22:32PM +0100, Thomas Neumann via Gcc-patches wrote:
> > When dynamically linking a fast enough machine hides the latency, but when
> > Statically linking or on slower devices this change caused a 5x increase in
> > Instruction count and 2x increase in cycle count before
Hi,
When dynamically linking a fast enough machine hides the latency, but when
Statically linking or on slower devices this change caused a 5x increase in
Instruction count and 2x increase in cycle count before getting to main.
This has been quite noticeable on smaller devices. Is there a reas
Hi,
I couldn't find a Bugzilla account for you Thomas,
I've bisected a slowdown in startup speed for C++ to this change,
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107675
When dynamically linking a fast enough machine hides the latency, but when
Statically linking or on slower devices thi
On 19/09/2022 17:33, Thomas Neumann wrote:
Can you try if the patch below fixes the problem? It keeps the data
structures alive at shutdown, though, which will probably make some leak
detectors unhappy.
Alternatively we could simply remove the gcc_assert (ob) in line 285 of
that file. As far
At least when building LibreOffice with Clang (16 trunk) with ASan and
UBsan enabled against libstdc++ (with --gcc-toolchain and
LD_LIBRARY_PATH to pick up a libstdc++ trunk build including this change
at build and run-time), at least one of the LibreOffice tests executed
during the build st
On 19/09/2022 15:55, Thomas Neumann wrote:
Apparently a registered frame is not found when deregistering, which
triggers an assert. I will debug this. Could you send me a script or a
description on how to reproduce the issue?
Thanks a lot! I'm in the process of checking whether a more generic
I haven't debugged this in any way, nor checked whether it only impacts
exactly my below scenario, but noticed the following:
At least when building LibreOffice with Clang (16 trunk) with ASan and
UBsan enabled against libstdc++ (with --gcc-toolchain and
LD_LIBRARY_PATH to pick up a libstdc++
On 16/09/2022 12:19, Thomas Neumann via Gcc-patches wrote:
The __register_frame/__deregister_frame functions are used to register
unwinding frames from JITed code in a sorted list. That list itself
is protected by object_mutex, which leads to terrible performance
in multi-threaded code and is som
Hi Dimitar,
This patch broke avr and pru-elf cross builds:
gcc/libgcc/unwind-dw2-fde.c:680:28: error: unknown type name ‘uintptr_t’
680 |uintptr_t *range)
Should uintptr_t be replaced with __UINTPTR_TYPE__? Such change fixes the
above broken builds for me. But
Hi Dimitar,
This patch broke avr and pru-elf cross builds:
gcc/libgcc/unwind-dw2-fde.c:680:28: error: unknown type name ‘uintptr_t’
680 |uintptr_t *range)
Should uintptr_t be replaced with __UINTPTR_TYPE__? Such change fixes the
above broken builds for me. But
On Fri, Sep 16, 2022 at 12:19:36PM +0200, Thomas Neumann via Gcc-patches wrote:
> The __register_frame/__deregister_frame functions are used to register
> unwinding frames from JITed code in a sorted list. That list itself
> is protected by object_mutex, which leads to terrible performance
> in mul
On 9/16/22 06:19, Thomas Neumann wrote:
The __register_frame/__deregister_frame functions are used to register
unwinding frames from JITed code in a sorted list. That list itself
is protected by object_mutex, which leads to terrible performance
in multi-threaded code and is somewhat expensive eve
18 matches
Mail list logo
