Just in case if it matters :)
I am still really interested in this patch merged in.
BR,
Denis
2015-08-01 20:38 GMT+03:00 Vyacheslav Egorov <dmarc-noreply@xxxxxxxxxxxxx>:
First, this is similar in style to lj_opt_fwd_href_nokey(). Check
where this is used and find the rule LJFOLD(HREF TNEW any) in
lj_opt_fold.c. That's where you'd want to anchor such an
optimization.
I noticed that rule - but in this particular case I wasn't sure if I
should add a new folding rule (e.g. in this case for "HREF any TNEW"
and "HREF any TDUP") or just "enrich" the existing one.
I reasoned that if "HREF any TNEW" rule fails to fold then eventually
"HLOAD any" will be called anyway. Which means no matter where we put
our code we are not changing anything related to the cost of the
optimization assuming that the cost of checking the precondition
(whether we are in HLOAD (HREF any TNEW|TDUP) case or not) is
marginal.
So the only obvious to me cost benefit from having a separate folding
rule was IR size (folding early vs. folding late).
My original intent was also to write a more complicated rule - which
would take both keys' and tables' aliasing into account - but as you
say, I realized that this an uncommon case and wrote a simpler loop.
Handling a more generic case is theoretically interesting by probably
impractical.
Now I see that moving this check into a separate folding rule would
lead to a better structured code.
Would you like me to rework this patch in this way and send it to you?
Anyway, that's probably not the answer you expected. :-) Instead
of either reworking or dropping your patch, I thought it would be
helpful to go on a tangent and explain the reasoning I'd follow,
but leave the ultimate decision in your hands.
It's a great answer really. Optimizing compilers I worked on before
(like V8 or Dart VM) are mostly about peak performance and not
footprint, so for me it's extremely interesting to try and operate
under stricter rules.
// Vyacheslav Egorov
