Currently the cost model under-estimates the cost of certain
FP16 conversions.
This patch updates getCastInstrCost to return more accurate costs for
the cases improved in c2ed9fd05479.
Note that this does not fix the incorrect costs without FULLFP16 so far.
I'm not sure if there's a good generic way to estimate those costs
better, without explicitly adding a large number of combinations to the
table. Perhaps we could return a larger cost if we cannot match the
operation in any table?
Use update_analyze_test_checks. You may find it is better to move the half checks to a separate function.