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

[perl #116989] S_croak_memory_wrap breaks gcc warning flags detection

From:
bulk88 via RT
Date:
March 28, 2013 01:08
Subject:
[perl #116989] S_croak_memory_wrap breaks gcc warning flags detection
Message ID:
rt-3.6.HEAD-28177-1364432924-1259.116989-15-0@perl.org
On Wed Mar 27 18:00:17 2013, bulk88 wrote:
> 
> 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.

Forgot to mention, the above numbers assume croak_memory_wrap() is a XS
library, not the interp (perl517.dll). They also assume the compiler
wasn't set to "aggressive inline" mode and inlined all the
S_croak_memory_wrap calls, which could happen. Inside the interp, a
jmp_conditional relative_32_bits_to_current_instruction_register can
still be done, since it is within the same image.

-- 
bulk88 ~ bulk88 at hotmail.com

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



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