summaryrefslogtreecommitdiff
path: root/sv_inline.h
Commit message (Collapse)AuthorAgeFilesLines
* sv.h - add SvREFCNT_dec_set_NULL()Yves Orton2023-03-181-0/+12
| | | | | | | | | | | | | | | and also SvREFCNT_dec_ret_NULL() which is used to implement SvREFCNT_dec_set_NULL(). The set_NULL() macro is intended to be used to replace code like this: if (sv) { SvREFCNT_dec_NN(sv); sv = NULL; } The function form just facilitates it, and can be used in situations where returning NULL after decrementing a refcount would be reduce code complexity.
* Create a specific SV type for object instancesPaul "LeoNerd" Evans2023-02-101-3/+20
|
* SvPVCLEAR_FRESH - change from macro to inline functionRichard Leach2022-09-221-0/+15
| | | | | This is to prevent warnings due to the char * frequently being unused.
* Perl_newRV_noinc - explicitly simplify, convert to inline funcRichard Leach2022-08-051-0/+25
| | | | | | | | | | | | Perl_newRV_noinc creates a new SVt_IV, then calls sv_setrv_noinc, which will check if the SVt_IV is SvTHINKFIRST (it won't be) and if it is types other than SVt_IV (it won't be). If those checks and associated branches are removed, all that remains is some flag twiddling and setting the sv_u.svu_rv pointer. A decent compiler *might* figure that all out and simplify Perl_newRV_noinc right down to the essentials, but if we do that directly, the entire function is small enough to move to sv_inline.h
* Fix compilation errors in netbsd/solarisKarl Williamson2022-07-011-24/+24
| | | | | | | | | These were introduced by 1ef9039bccbfe64f47f201b6cfb7d6d23e0b08a7. The compilers in question die if something that is "forced to be inlined' cannot be. So, change to merely request inlining. Also change the order of definition to try to avoid forward references to make it easier to inline.
* Eval param to SvPV-foo exactly onceKarl Williamson2022-06-291-0/+79
| | | | | This changes all the API macros that retrieve a PV into a call to an inline function so as to evaluate the parameter just once.
* Follow on to 6d21409fd4b749511b9ec73e2dbaaff513f6eae8Karl Williamson2022-06-181-6/+6
| | | | | This was meant to be a part of the previous commit, but somehow got omitted.
* SvGETMAGIC: evaluate its argument just onceKarl Williamson2022-06-101-0/+19
| | | | | | | This required making it into an inline function. I tried using STMT_START{ ... } STMT_END, which should work since it has a void return, but there were places where it was used in a comma operator, and those did not compile.
* Move sv.h functions from inline.h into sv_inline.h,Richard Leach2022-05-281-0/+303
| | | | | so that all functions inlined from sv.* are in one place. This was suggested by @khw.
* Perl_newSV_type_mortal - new inline function introduced and usedRichard Leach2022-03-071-8/+45
| | | | | | | | | | | | | | | There's no efficient way to create a mortal SV of any type other than SVt_NULL (via sv_newmortal). The options are either to do: * SV* sv = sv_newmortal; sv_upgrade(sv, SVt_SOMETYPE); but sv_upgrade is needlessly inefficient on new SVs. * SV* sv = sv_2mortal(newSV_type(SVt_SOMETYPE) but this will perform runtime checks to see if (sv) and if (SvIMMORTAL(sv), and for a new SV we know that those answers will always be yes and no. This commit adds a new inline function which is basically a mortalizing wrapper around the now-inlined newSV_type.
* Make newSV_type an inline functionRichard Leach2022-03-071-0/+495
When a new SV is created and upgraded to a type known at compile time, uprooting a SV head and then using the general-purpose upgrade function (sv_upgrade) is clunky. Specifically, while uprooting a SV head is lightweight (assuming there are unused SVs), sv_upgrade is too big to be inlined, contains many branches that can logically be resolved at compile time for known start & end types, and the lookup of the correct body_details struct may add CPU cycles. This commit tries to address that by making newSV_type an inline function and including only the parts of sv_upgrade needed to upgrade a SVt_NULL. When the destination type is known at compile time, a decent compiler will inline a call to newSV_type and use the type information to throw away all the irrelevant parts of the sv_upgrade logic. Because of the spread of type definitions across header files, it did not seem possible to make the necessary changed inside sv.h, and so a new header file (sv_inline.h) was created. For the inlined function to work outside of sv.c, many definitions from that file were moved to sv_inline.h. Finally, in order to also benefit from this change, existing code in sv.c that does things like this: SV* sv; new_SV(sv); sv_upgrade(sv, SVt_PV) has been modified to read something like: SV* sv = newSV_type(SVt_PV);