develooper Front page | perl.perl5.porters | Postings from March 2013

[perl #116989] S_croak_memory_wrap breaks gcc warning flags detection

Thread Previous | Thread Next
From:
bulk88 via RT
Date:
March 28, 2013 01:00
Subject:
[perl #116989] S_croak_memory_wrap breaks gcc warning flags detection
Message ID:
rt-3.6.HEAD-28177-1364432417-725.116989-15-0@perl.org
On Wed Mar 27 13:11:35 2013, doughera wrote:
> 
> This is the tact I tried in commit
f8fd8bfff8eb57156a0ab858d4c185701258b0e3
> in branch remotes/origin/smoke-me/andyd/croak_memory_wrap.
> 
> I'd welcome feedback.  I'm no longer sure it ends up saving anything
> compared to the original Perl_croak_nocontext("%s", PL_memory_wrap),
> but this seemed like the best way forward for now.
> 

Summary, on Win32, new way (8 bytes) is slightly worse than before (5 or
7 bytes), but still better than the original situation (19 bytes). Its ok.

On Win32 (not discussing any other OS), Perl_croak_memory_wrap is still
a savings. On VC 2003 32 bit , it will now probably (I didn't compile
f8fd8bfff8eb57156a0ab858d4c185701258b0e3) be
____________________________________________
jmp_conditional didnt_wrap (2 bytes)
call *(image_import_table_Perl_croak_memory_wrap) (6 bytes)
didn't_wrap:
____________________________________________
which is still shorter than
________________________________________________
jmp_conditional didnt_wrap (2 bytes)
push *(image_import_table_PL_memory_wrap) (6 bytes)
push in_image_%s_fmt_string (5 bytes)
call *(image_import_table_Perl_croak_nocontext) (6 bytes)
didn't_wrap:
________________________________________________

As a static non-inline previously, *ideally* (C compiler dependent) it
would have been
________________________________________________
jmp_conditional relative_to_croak_memory_wrap (5 bytes)
________________________________________________

Visual C 2003 in 32 bit mode I remember did
________________________________________________
jmp_conditional didnt_wrap (2 bytes)
jmp_unconditional in_image_S_croak_memory_wrap (5 bytes)
didn't_wrap:
________________________________________________
which is strange and unideal, (I will guess, in the internal design of
VC, it probably has to do with the 1st jump being a flow control
bytecode op, and the 2nd jump being the func call bytecode op).

In theory, a C compiler could do (VC will do this in debug mode to
enable
http://msdn.microsoft.com/en-us/library/bcew296c%28v=vs.80%29.aspx ),
looking at my 5.12 Strawberry (GCC -O2), it does NOT do this)

________________________________________________
jmp_conditional relative_to_Perl_croak_memory_wrap_stub (5 bytes)
didn't_wrap:
________________________________________________
somewhere else in the image, once per image, there is the following function
________________________________________________
jmp_unconditional *(image_import_table_Perl_croak_memory_wrap) (6 bytes)
________________________________________________

But I guess there is a performance problem with doing that so it just
isn't done by any Windows C compiler in an optimized build.

-- 
bulk88 ~ bulk88 at hotmail.com

---
via perlbug:  queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=116989

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About