Re: Undefined variables undefined order

Hi Sara, ----- Original Message ----- From: "Sara Golemon" Sent: Wednesday, June 10, 2015

On Tue, Jun 9, 2015 at 6:05 AM, Matt Wilmas <php_lists@realplain.com> wrote:

Hah, looks like this just changed last week after barely 3 weeks. :-P I didn't verify, just noticed the code change: http://git.php.net/?p=php-src.git;a=commitdiff;h=c09698753e7d1d95299dca54c8ca888c885fd45b

Dmitry, what's the reasoning behind this diff in the first place? Doesn't the compiler fold (<const-string> . <const-string>) already anyhow? How would we wind up with CONCAT_CONST_CONST at runtime?

Now CONCAT is consistent, but not others. Which places need changing anyway? Just binary ops in VM? A couple/few extra instructions are unavoidable, I guess on any architecture, for the intermediate save of op1, but can anyone show that it makes ANY measurable difference (other than instruction count)?

I'm 90% certain that fixing the ordering (by saving to a temp var) doesn't *actually* result in extra instructions. GCC's optimizer is pretty clever. It'll notice you're only writing to the temp var once, and reading from it once (immediately), so it'll end up organizing the instructions in a way which satisfies the explicit order, but as an inline call.

I don't know... Yeah, if op1 is coming from a "plain" variable, either something simple (like CONST?) or after function inlining. e.g. Like "directly" accessible, then it should be able to be done the same. (I don't know a lot about any of this though.) I was thinking of when some sort of function call is involved (as far as unavoidable extra instructions). If op1 is fetched after op2, it's optimized for passing to concat_function(), etc. Doing stuff in reverse order will need fewer instructions than "human order," at least when function calls are needed for "stuff." Hmm, maybe that's only for x86 with push'ed args, where each thing can keep push'ing whatever it needs (eax) for the final (outer) function... x86_64 is I guess still going to need to store stuff "out of the way" for the next (inner) call, before moving it back to the necessary registers for the final function! If that's true, maybe x86_64 doesn't need more instructions. I think I've confused myself more trying to picture what's happening. :-O

-Sara

- Matt