slag-developers — Developer Discussions

[<sla...@li...>]

I like your idea -- it is an attractive way to do a parameter
fit to things like

  1) thread/no-thread
  2) decide average loop size
  3) control unrolling
  4) etc...

The old SISAL compiler did the optimizations statically where it
would unroll to some degree (under control of a user option) --
a lot like FORTRAN would.

I think we should similarly target large loops (Currently uses a
static analysis to guestimate the cost of a loop) and then take
advantage of functional programming to do

       X
   /   |   \
  L0   L1  L2
   \   |   /
    \  |  /
     \ | /
       Y

That is, we pick that big loop.  Do a sort of fork/join to try the
multiple variants, pick one of the results, and continue.  We could
use this approach to create a feedback to the compiler for the "money"
run.

We did something like this to gather dynamic loop runtime costs though
the mechanism was clunky (each loop had a unique ID that was carried
through compilation and expressed in the statistics gatherer, then
the dynamic cost was merged in when we made parallel partitioning
decisions.

Pat