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
* 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
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
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
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
lorian Weimer ; Jakub Jelinek
> ; Jonathan Wakely
> Subject: [PATCH v4] eliminate mutex in fast path of __register_frame
>
> The __register_frame/__deregister_frame functions are used to register
> unwinding frames from JITed code in a sorted list. That list itself is
> protected
>
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
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
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
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
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
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 even if single-threaded.
There was already
19 matches
Mail list logo
