| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This macro will inline the code to determine if a character is
well-formed UTF-8 for code points below a certain value, falling back to
a slower function for larger ones. On ASCII platforms, it will inline
for well-beyond all legal Unicode code points. On EBCDIC, it currently
does it for code points up to 0x3FFF. This could be increased, but our
porting tests do the regen every time to make sure everything is ok, and
making it larger slows that down. This is worked around on ASCII by
normally commenting out the code that generates this info, but including
in utf8.h a version that did get generated. This is static information
and won't change. (This could be done for EBCDIC too, but I chose not
to at this time as each code page has a different macro generated, and
it gets ugly getting all of them in utf8.h)
Using this macro allowed for simplification of several functions in
utf8.c
|
| |
|
|
|
| |
This is in preparation for it being called from outside utf8.c. It is
renamed to have a leading underscore to emphasize its private nature
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This effectively reverts commit 3ded5eb052cdc3f861ec0c0ff85348086d653be0.
That commit created a scheme to bootstrap Perl onto a non-ASCII
platform, by adding the allowing a Configure option that caused the
compiled code to bypass a number of normal macro definitions and use
slower, generic ones, sufficient to get miniperl to compile on the
target architecture. One would then use miniperl to run a few scripts
that would re-order certain header files, Using this one could then
recompile all of perl, and once that was done, use it to recompile to
use the normal fast macros.
This worked, but was a cumbersome process. We now have the
infrastructure, since commit 6ff677df5d6fe0f52ca0b6736f8b5a46ac402943,
to cross compile on an ASCII platform to EBCDIC, the likely only
non-ASCII character set to ever be used. So the new infrastructure will
be used in future commits.
|
| |
|
|
|
|
| |
This makes the uses of this consistent in our pods. Also changed one
use of the word 'buffer' into 'string', the latter being more
appropriate.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
This removes a macro not yet even in a development release, and splits
its calls into two classes: those where the input is a byte; and those
where it can be any unsigned integer. The byte implementation avoids a
function call on EBCDIC platforms.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This adds a bunch of macros and moves things around to support
conditional compilation when Configure is called with
-DBOOTSTRAP_CHARSET. Doing so causes the usual macros that are
table-driven to not be used, since the table may not be valid when
bringing Perl up for the first time on a non-ASCII platform.
This allows it to compile using the platform's native C library ctype
functions, which should work enough to compile miniperl, and allow the
table to be changed to be valid. Then Configure can be re-run to not
bootstrap, and normal compilation can proceed
|
| |
|
|
| |
These areas of code included a temporary that is unnecessary.
|
| |
|
|
|
| |
This fairly short paradigm is repeated in several places; a later commit
will improve it.
|
| |
|
|
|
| |
ckWARN calls Perl_ckwarn. So does Perl_ck_warner. So there is no
need to use both.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Check for the nul char in pathnames and string arguments to
syscalls, return undef and set errno to ENOENT.
Added to the io warnings category syscalls.
Strings with embedded \0 chars were prev. ignored in the syscall but
kept in perl. The hidden payloads in these invalid string args may cause
unnoticed security problems, as they are hard to detect, ignored by
the syscalls but kept around in perl PVs.
Allow an ending \0 though, as several modules add a \0 to
such strings without adjusting the length.
This is based on a change originally by Reini Urban, but pretty much
all of the code has been replaced.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The value of pos() is stored as a byte offset. If it is stored on a
tied variable or a reference (or glob), then the stringification could
change, resulting in pos() now pointing to a different character off-
set or pointing to the middle of a character:
$ ./perl -Ilib -le '$x = bless [], chr 256; pos $x=1; bless $x, a; print pos $x'
2
$ ./perl -Ilib -le '$x = bless [], chr 256; pos $x=1; bless $x, "\x{1000}"; print pos $x'
Malformed UTF-8 character (unexpected end of string) in match position at -e line 1.
0
So pos() should be stored as a character offset.
The regular expression engine expects byte offsets always, so allow it
to store bytes when possible (a pure non-magical string) but use char-
acters otherwise.
This does result in more complexity than I should like, but the alter-
native (always storing a character offset) would slow down regular
expressions, which is a big no-no.
|
| |
|
|
|
|
|
|
|
|
| |
Make the array interface 64-bit safe by using SSize_t instead of I32
for array indices.
This is based on a patch by Chip Salzenberg.
This completes what the previous commit began when it changed
av_extend.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit c82ecf346.
It turn out to be faulty, because a location shared betweens threads
(the cop) was holding a reference count on a pad entry in a particu-
lar thread. So when you free the cop, how do you know where to do
SvREFCNT_dec?
In reverting c82ecf346, this commit still preserves the bug fix from
1311cfc0a7b, but shifts it around.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This saves having to allocate a separate string buffer for every cop
(control op; every statement has one).
Under non-threaded builds, every cop has a pointer to the GV for that
source file, namely *{"_<filename"}.
Under threaded builds, the name of the GV used to be stored instead.
Now we store an offset into the per-interpreter PL_filegvpad, which
points to the GV.
This makes no significant speed difference, but it reduces mem-
ory usage.
|
| |
|
|
|
|
|
|
|
| |
This reverts commit 43387ee1abcd83c3c7586b7f7aa86e838d239aac.
Which reverted parts of f019c49e380f764c1ead36fe3602184804292711, but that
reversion may no longer be necessary.
See [perl #116989]
|
| | |
|
| |
|
|
| |
prototypes assumes spaces were already gone, which may not be true if they were added via XS / set_prototype.
|
| |
|
|
|
|
|
|
|
| |
When decrementing the refcount on an SV, we have to branch on whether or
not we've reached a refcount of 0. But a quick instrumentation shows
that in virtually any program small or large, the number of decrements
without freeing greatly outweighs the number of decrements that cause a
free. Therefore, it's a net win to suggest to the compiler to emit a
branch prediction hint to go into the just-decrement branch.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This appears to resolve these three related tickets:
[perl #116989] S_croak_memory_wrap breaks gcc warning flags detection
[perl #117319] Can't include perl.h without linking to libperl
[perl #117331] Time::HiRes::clock_gettime not implemented on Linux (regression?)
This patch changes S_croak_memory_wrap from a static (but not inline)
function into an ordinary exported function Perl_croak_memory_wrap.
This has the advantage of allowing programs (particuarly probes, such
as in cflags.SH and Time::HiRes) to include perl.h without linking
against libperl. Since it is not a static function defined within each
compilation unit, the optimizer can no longer remove it when it's not
needed or inline it as needed. This likely negates some of the savings
that motivated the original commit 380f764c1ead36fe3602184804292711.
However, calling the simpler function Perl_croak_memory_wrap() still
does take less set-up than the previous version, so it may still be a
slight win. Specific cross-platform measurements are welcome.
|
| |
|
|
|
|
|
|
| |
This adds branch prediction hints to a few strategic places such as
growing stack or strings, some exception handling, and a few hot
functions such as sv_upgrade.
This is not exhaustive by any means.
|
| |
|
|
|
| |
This function is just an assert and a macro call. Avoid the function
call overhead by making it inline.
|
| |
|
|
|
|
|
|
|
|
|
| |
These macros should not be used as they are prone to misuse. There are
no occurrences of them in CPAN. The single use of either of them in
core has recently been removed (commit
8d40577bdbdfa85ed3293f84bf26a313b1b92f55), because it was a misuse.
Instead code should use isIDFIRST_lazy_if or isWORDCHAR_lazy_if
(isALNUM_lazy_if is also available, but can be confused with the Posix
alnum, which it doesn't mean).
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
ccde85316a0db149f30359ebfdf031ef602b0344 added some
#pragma clang ...
lines to shut up clang.
This caused gcc to give voluminous 'unknown pragma "clang"' output.
Sigh.
Hopefully now fixed, although it all seems very cumbersome.
|
| |
|
|
|
|
|
|
| |
principally, proto.h was sometimes being included twice - once before
a fn decl, and once after - giving rise to a 'decl after def' warning.
Also, S_croak_memory_wrap was declared static in every source file, but
not used in some. So selectively disable the unused-function warning.
|
| |
|
|
|
|
|
|
|
| |
Like SvREFCNT_dec(), but skips the not null check, making code potentially
smaller and faster.
Also as proof of concept, updates the SvREFCNT_dec's in scope.c where
it's obvious the value can't be NULL. There are still 500+ uses in the
perl core that need evaluating!
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Historically, SvREFCNT_dec was just
#define SvREFCNT_dec(sv) sv_free((SV*)(sv))
then in 5.10.0, for GCC, the macro was partially inlined, avoiding a
function call for the refcnt > 1 case. Recently, the macro was turned into
an inline function, providing the function-call avoidance to other
platforms too. However, the macro/inline-function is quite big, and
appears over 500 times in the core source. Its action is logically
equivalent to:
if (sv) {
if (SvREFCNT(sv) > 1)
SvREFCNT(sv)--;
else if (SvREFCNT == 1) {
// normal case
SvREFCNT(sv)--;
sv_free2(sv);
}
else {
// exceptional case
sv_free(sv);
}
}
Where sv_free2() handles the "normal" quick cases, while sv_free()
handles the odd cases (e,g. a ref count already at 0 during global
destruction).
This means we have to plant code that potentially calls two different
subs, over 500 times.
This commit changes SvREFCNT_dec and sv_free2() to look like:
PERL_STATIC_INLINE void
S_SvREFCNT_dec(pTHX_ SV *sv)
{
if (sv) {
U32 rc = SvREFCNT(sv);
if (rc > 1)
SvREFCNT(sv) = rc - 1;
else
Perl_sv_free2(aTHX_ sv, rc);
}
}
Perl_sv_free2(pTHX_ SV *const sv, const U32 rc)
{
if (rc == 1) {
SvREFCNT(sv) = 0;
... do sv_clear, del_SV etc ...
return
}
/* handle exceptional rc == 0 */
...
}
So for the normal cases (rc > 1, rc == 1) there is the same amount of
testing and function calls, but the second test has been moved inside
the sv_free2() function.
This makes the perl executable about 10-15K smaller, and apparently a bit
faster (modulo the fact that most benchmarks are just measuring noise).
The refcount is passed as a second arg to sv_free2(), as on platforms
that pass the first few args in registers, it saves reading sv->sv_refcnt
again.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since the xpvlv and regexp structs conflict, we have to find somewhere
else to put the regexp struct.
I was going to sneak it in SvPVX, allocating a buffer large
enough to fit the regexp struct followed by the string, and have
SvPVX - sizeof(regexp) point to the struct. But that would make all
regexp flag-checking macros fatter, and those are used in hot code.
So I came up with another method. Regexp stringification is not
speed-critical. So we can move the regexp stringification out of
re->sv_u and put it in the regexp struct. Then the regexp struct
itself can be pointed to by re->sv_u. So SVt_REGEXPs will have
re->sv_any and re->sv_u pointing to the same spot. PVLVs can then
have sv->sv_any point to the xpvlv body as usual, but have sv->sv_u
point to a regexp struct. All regexp member access can go through
sv_u instead of sv_any, which will be no slower than before.
Regular expressions will no longer be SvPOK, so we give sv_2pv spec-
ial logic for regexps. We don’t need to make the regexp struct
larger, as SvLEN is currently always 0 iff mother_re is set. So we
can replace the SvLEN field with the pv.
SvFAKE is never used without SvPOK or SvSCREAM also set. So we can
use that to identify regexps.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Most perls are built with PERL_MALLOC_WRAP. This causes MEM_WRAP_CHECK
macro to perform some checks on the requested allocation size in macro
Newx. The checks are performed at the caller, not in the callee (for me
on Win32 perl the callee in Newx is Perl_safesysmalloc) of Newx.
If the check fails a "Perl_croak_nocontext("%s",PL_memory_wrap)" is done.
In x86 machine code,
"if(bad_alloc) Perl_croak_nocontext("%s",PL_memory_wrap); will be written
as "cond jmp ahead ~15 bytes", "push const pointer", "push const pointer",
"call const pointer". For each Newx where the allocation amount was not a
constant (constant folding would remove the croak memory wrap branch
compleatly), the branch takes 15-19 bytes depending on x86 compiler. There
are about 80 Newx'es in the interp (win32 dynamic linking perl) that do
the memory wrap check and have a
"Perl_croak_nocontext("%s",PL_memory_wrap)" in them after all optimizations
by the compiler.
This patch reduces the memory wrap branch from 15-19 to
5 bytes on x86. Since croak_memory_wrap is a static and a noreturn, a
compiler with IPO may optimize the whole branch to "cond jmp 32 bits
relative" at each callsite. A less optimal complier may do "cond jmp 8 bits
relative (jump past the "call S_croak_memory_wrap" instruction),
then "call S_croak_memory_wrap". Both ways are better than the current
situation. The reason why croak_memory_wrap is a static and not an export
is that the compiler has more opportunity to optimize/reduce the impact of
the memory wrap branch at the call site if the target is in the same image
rather than in a different image, which would require using the platform
specific dynamic linking mechanism/export table/etc, which often requires
a new stack frame per ABI of the platform. If a dynamic linked XS module
does not use S_croak_memory_wrap it will be removed from the image by the
C compiler. If it is included in the XS image, it is a very small block
of code and a 3 byte string litteral. A CPU cache line is typically
32 or 64 bytes and a memory read is typically 16. Cutting the
instructions by 10 to 16 bytes out of "hot code" (10 of the ~80 call
sites are pp_*) is a worthy goal. In a few places the memory wrap croak is
used explictly, not from a MEM_WRAP_CHECK, this patch converts those to use
the static. If PERL_MALLOC_WRAP is undef, there are still a couple uses of
croak memory wrap, so do not keep S_croak_memory_wrap in a ifdef
PERL_MALLOC_WRAP. Also see
http://www.nntp.perl.org/group/perl.perl5.porters/2012/10/msg194383.html
and [perl #115456].
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
As Dave Mitchell pointed out, while putting the CvDEPTH field for for-
mats in the SvCUR slot might save memory for formats, it slows down
sub calls because CvDEPTH is used on subs in very hot code paths.
Checking the SvTYPE to determine which field to use should not be
necessary.
|
| |
|
|
|
| |
This allows us to use assert() inside S_CvDEPTHp, so we no longer need
GCC and non-GCC variants of the macro that calls it.
|
| |
|
|
|
| |
This allows non-GCC compilers to have assertions and avoids
repeating the macros.
|
| | |
|
| |
|
|
|
|
| |
This avoids the need to repeat the macros in GCC and non-GCC versions.
For non-GCC compilers capable of inlining, this should speed things up
slightly, too, as PL_Sv is no longer needed.
|
|
|
We can put static inline functions here, and they can depend on
function prototypes and struct definitions from other header
files.
|
