The variable PL_reginput (which is actually part of the global/per-interpreter variable PL_reg_state), is mainly used just locally within the S_regmatch() function. In this role, it effectively competes with the local-to-regmatch() variable locinput, as a pointer that tracks the current match position. Having two variables that do this is less efficient,and makes the code harder to understand. So this series of commits: 1) removes PL_reginput, and replaces it with a var, reginput, local to regmatch(); 2) successively removes more and uses of the reginput variable, until 3) it is eliminated altogether, leaving locinput as the sole 'here we are' pointer. Looking at the CPU usage of running the t/re/*.t tests on a -O2, non-threaded build, running each test suite 3 times, gives: before: 55.35 55.66 55.69 after: 55.10 55.13 55.33 which indicates a small performance improvement of around 0.5%. (The CPU usage of a single run of the whole perl test suite dropped from 783.31s to 777.23s).
reginput, locinput and st->locinput were being used in a little ballet to determine the length of the first match. This is now simply locinput - st->locinput, or its unicode equivalent; so the code can be simplified. Elsewhere in the block: where reginput was being used, locinput and/or nextchr already contain the same info, so use them instead. This is part of a campaign to eliminate the reginput variable.
It was being used essentially as a temporary var within the branch, so replace it with a temp var in a new block scope. On return in IFMATCH_A / IFMATCH_A_fail, there's no need to set reginput any more, so don't. The SUSPEND case used to set locinput = reginput, but at that point, the two variables already always had the same value anyway. This is part of a campaign to eliminate the reginput variable.
Currently, the string position from where matching continues after a PUSH is implicitly specified by the value of reginput, which is usually just equal to locinput. Make this explicit by adding an extra argument to PUSH_STATE_GOTO() etc. This is part of a campaign to eliminate the reginput variable.
PL_reginput (which is actually #defined to PL_reg_state.re_state_reginput) is, to all intents and purposes, state that is only used within S_regmatch(). The only other places it is referenced are in S_regtry() and S_regrepeat(), where it is used to pass the current match position back and forth between the subs. Do this passing instead via function args, and bingo! PL_reginput is now just a local var of S_regmatch().
These have been present since PERL_POISON was added in June 2005 by commit 94010e7. It seems that no-one has tried compiling with both defined together.
…est. The code had been buggily attempting to overwrite just-freed memory since PERL_POISON was added by commit 94010e7 in June 2005. However, no regression test exercised this code path until recently. Also fix the offset in the array of UVs used by PERL_OLD_COPY_ON_WRITE to store RX_SAVED_COPY(). It now uses p. Previously it had used p, directly conflicting with the use of p to store RX_NPARENS(). The code is too intertwined to meaningfully do these as separate commits.
… by hand. With minor change from committer: Always assign $@ asap after an eval.
I started this work planning to enhance regen/regcharclass.pl to accept Unicode properties as input so that some small properties used in \X could be compiled in, instead of having to be read from disk. In doing so, I saw some opportunities to move some EBCDIC dependencies down to a more basic level, thus replacing quite a few existing ones with just a couple at the lower levels. This also led to my enhancing the macros output by regcharclass.pl to be at least as good (in terms of numbers of branches, etc) as the hand-coded ones it replaces. I also spotted a few bugs in existing code that hadn't been triggered yet.
This takes the output of regen/regcharclass.pl for all the 1-4 byte UTF8-representations of Unicode code points, and replaces the current hand-rolled definition there. It does this only for ASCII platforms, leaving EBCDIC to be machine generated when run on such a platform. I would rather have both versions to be regenerated each time it is needed to save an EBCDIC dependency, but it takes more than 10 minutes on my computer to process the 2 billion code points that have to be checked for on ASCII platforms, and currently t/porting/regen.t runs this program every times; and that slow down would be unacceptable. If this is ever run under EBCDIC, the macro should be machine computed (very slowly). So, even though there is an EBCDIC dependency, it has essentially been solved.
This adds the capability to skip definitions if they are for other than a desired platform.
regen/regcharclass.pl has been enhanced in previous commits so that it generates as good code as these hand-defined macro definitions for various UTF-8 constructs. And, it should be able to generate EBCDIC ones as well. By using its definitions, we can remove the EBCDIC dependencies for them. It is quite possible that the EBCDIC versions were wrong, since they have never been tested. Even if regcharclass.pl has bugs under EBCDIC, it is easier to find and fix those in one place, than all the sundry definitions.
A previous commit added an optimization to save a branch in the generated code at the expense of an extra mask when the input class has certain characteristics. This extends that to the case where sub-portions of the class have similar characteristics. The first optimization for the entire class is moved to right before the new loop that checks each range in it.
This adds a test and returns 1 from a subroutine if the condition will always match; and in the caller it adds a check for that, and omits the condition from the generated macro.
This is to prepare for future commits which will act differently at the deep level depending on some of the options.
The rules for matching whether an above-Latin1 code point are now saved in a macro generated from a trie by regen/regcharclass.pl, and these are now used by pp.c to test these cases. This allows removal of a wrapper subroutine, and also there is no need for dynamic loading at run-time into a swash. This macro is about as big as I'm comfortable compiling in, but it saves the building of a hash that can grow over time, and removes a subroutine and interpreter variables. Indeed, performance benchmarks show that it is about the same speed as a hash, but it does not require having to load the rules in from disk the first time it is used.
One of these functions is currently commented out. The other is called only in regexec.c in one place, and was recently revised to no longer require the static function in utf8.c that it formerly called. They can be made static inline.
A previous commit has caused macros to be generated that will match Unicode code points of interest to the \X algorithm. This patch uses them. This speeds up modern Korean processing by 15%. Together with recent previous commits, the throughput of modern Korean under \X has more than doubled, and is now comparable to other languages (which have increased themselved by 35%)