(Investigate) improving LICM

Loop invariant code motion (LICM) schedules instructions related to the frequency of the basic block they are contained within. When scheduling in blocks with the same frequency the instructions can be scheduled:

early - close to source operands but furthest from destination operands
late - far from source operands but close to destination operands not moved - this means they will either be early, late or somewhere in between. The cost in not moving an instruction in the LICM phase should be cheaper than moving it.

Currently LICM schedules instructions late based on an evaluation by Martin Trapp in 2002.

It seems this should be re-evaluated on the current benchmarks for the RVM and also to consider the operands to the instruction. It could be logical that if the number of operands are:

<1 - it's worth scheduling the instruction as close to where it will be used as possible, to avoid keeping the value live in a register
1 - one use and one definition means things are balanced, instructions can either move or not. Not moving should save compiler time, moving early or late might get lucky with register pressure. If the block execution frequencies are not accurate, not moving should be the most conservative thing to do
>1 - scheduling the instruction close to where its operands will become available should mean the larger number of source operands are kept live
for the shortest period

This issue replaces SF RFE tracker #1660931.