Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109849
To: Nikita Popov <nikita.ppv@gmail.com>
CC: "internals@lists.php.net" <internals@lists.php.net>
Thread-Topic: [PHP-DEV] Optimizing assembly for spl_object_id(), fdiv(), etc
 in the JIT?
Thread-Index: AQHWGxz5+Txr028sTUe2R2cg2slM+KiKDdsAgAAG/cg=
Date: Sat, 25 Apr 2020 17:38:30 +0000
Message-ID:
 <DM6PR07MB6618E4126C6FB848A3353F27F9D10@DM6PR07MB6618.namprd07.prod.outlook.com>
References:
 <DM6PR07MB661819D3D9D654287317A56DF9D10@DM6PR07MB6618.namprd07.prod.outlook.com>,<CAF+90c_gQjxhsq8wXymXcRBT_FY=p0B-+ufmxz4tJ-9JfFpxcw@mail.gmail.com>
In-Reply-To:
 <CAF+90c_gQjxhsq8wXymXcRBT_FY=p0B-+ufmxz4tJ-9JfFpxcw@mail.gmail.com>
Accept-Language: en-CA, en-US
Content-Language: en-CA
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [2wJOHmjraGBsPLpDR2WKLaoyHmxX1I3n]
x-ms-publictraffictype: Email
x-incomingheadercount: 46
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: 62e96f03-e1ec-4383-9ed4-08d7e93f7872
x-ms-traffictypediagnostic: DM6NAM12HT170:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 KdLGiTUJAJHXUSCfQt5e1S2aCpNphAeV0Afc9KPHVhcmaPAs0ypCQ4Xcpdty/RJxut9hRCQnWBg2LPFevJysDsdxVUZZwEIdWpS8QL/K3ZEesjMB7yT/oifPQoGun6/txNNR2Mclv+4IKlyBpdPIKH98NcJvO1WS67Dg+wbfq9YojJZW1D3C9+gV4tR4iGQa2ceysEpRAuIAoH1JEHBz9w==
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:0;SRV:;IPV:NLI;SFV:NSPM;H:DM6PR07MB6618.namprd07.prod.outlook.com;PTR:;CAT:NONE;SFTY:;SFS:;DIR:OUT;SFP:1901;
x-ms-exchange-antispam-messagedata:
 SNECCKCwA2mGN1E14GIQzfKh4KtkB3Z28GM1uH/vxyIIaC9S2DUh9bLg2Vn9QKxYNfgDkpjtSm3TAd2cYycuLpdETSh5qTwLpVGksPCIOokQqckQI1OYD9pvu3c+W6+7/dQPZ9biPlEEY2mAI9IzFg==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 62e96f03-e1ec-4383-9ed4-08d7e93f7872
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Apr 2020 17:38:30.8604
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6NAM12HT170
Subject: Re: [PHP-DEV] Optimizing assembly for spl_object_id(), fdiv(), etc in
 the JIT?
From: tysonandre775@hotmail.com (tyson andre)

Hi Nikita,=0A=
=0A=
> Our general approach to this is to first add a VM opcode for the operatio=
n,=0A=
> which will also provide a benefit if the JIT is not used.=0A=
> There's already plenty of those, see ZEND_STRLEN for example.=0A=
> Adding JIT support for the opcode would then be the natural second step.=
=0A=
=0A=
I've seen those - I'd assume there'd be a long tail of functions such as pr=
eg_match()=0A=
without references, spl_object_id(), substr(), etc, that are called frequen=
tly, but not often enough to have their own opcodes.=0A=
=0A=
What about adding a new opcode types that combines INIT_FCALL, SEND_VAR (or=
 SEND_VAL for constants), and DO_ICALL for known internal functions?=0A=
Has that been proposed before?=0A=
This could be used when the arguments were inferred by opcache to have corr=
ect types.=0A=
=0A=
```=0A=
Old (in function where $x is known to be a non-reference object):=0A=
0001 INIT_FCALL 1 96 string("spl_object_id")=0A=
0002 SEND_VAR CV0($x) 1=0A=
0003 V2 =3D DO_ICALL=0A=
0004 T1 =3D INIT_ARRAY 1 (packed) CV0($x) V2=0A=
0005 RETURN T1=0A=
=0A=
New (after opcache):=0A=
0001 T1 =3D INIT_AND_DO_ICALL_1_ARG $x // op1=3D$x, op2 is unused, extended=
_value =3D enum value corresponding to spl_object_id()=0A=
0002 RETURN T1=0A=
```=0A=
=0A=
And fdiv() could become  INIT_AND_DO_ICALL_2_ARG $x $y op1=3D$x, op2 is $y,=
 extended_value =3D enum value corresponding to fdiv=0A=
This should give opcache the information it needs to continue tracking the =
definitions and uses of variables, as well as function return types.=0A=
=0A=
- I'd hope there'd be a performance improvement, due to not needing to look=
 up zend_function, using the native C stack for zvals instead of a dynamic =
stack, perform param type checks, etc.=0A=
=0A=
This would only accept constants and compiled variables of known good types=
 for functions that wouldn't emit notices or cause re-entry - temporary val=
ues (e.g. spl_object_id(some_function())) wouldn't be accepted.=0A=
=0A=
The C implementation for the new opcode could be a switch on extended_value=
 with enum values for dozens of commonly used functions=0A=
that weren't common enough for individual opcodes.=0A=
=0A=
Thanks,=0A=
- Tyson=