4.79X post-Loch Ness performance loss in histlp.sac

Bugzilla Link	709
Created on	May 13, 2010 20:20
Version	svn
OS	Linux
Architecture	PC
Attachments	crud.sac, crud.b11, crud.prelochness, xcrud.prelochness

Extended Description

Created an attachment (id=710)
Dan's pre-Loch Ness -b13 output
This is the most egregious of the remaining performance loss problems
introduced at Loch Ness. apex/histlp/histlp.sac now executes about 5X slower
than pre-Loch Ness.
The Loop_0 functions before and after look nearly identical, except for
these two lines:
  _pinl_3552__wlbsc_2356_sc_e = _idx_sel_( _ivesplit_5497, _isaa_4840_r_2);
  _pinl_3553__wlbsc_2357_sc_bound = [ _pinl_3552__wlbsc_2356_sc_e ];
ivesplit_5497 is 0, but the Loop_0 function header doesn't see that; it
sees it as an AKS int.
Similarly, _isaa_4840_r_2 is a parameter, but it is int[1], and
_pinl_3553__wlbsc_2357_sc_bound becomes that parameter in the recursive call.
So, the two lines are, effectively, a no-op. 
The picture is made a bit murkier by the fact that 
_pinl_3553__wlbsc_2357_sc_bound is also one of the results of
Loop_0.
I can see how LIR might have trouble pulling these lines out of the loop
function. If we can't fancy up LIR enough to do the job, perhaps we
can do an UNWLBSC traversal somewhere around the end of Phase 11.
This, however, would not work in the current code, because _ivesplit_5497
is not AKV.