# Changeset a2545593 for doc/theses

Ignore:
Timestamp:
Mar 13, 2019, 10:20:24 AM (4 years ago)
Branches:
aaron-thesis, arm-eh, cleanup-dtors, enum, forall-pointer-decay, jacob/cs343-translation, jenkins-sandbox, master, new-ast, new-ast-unique-expr, pthread-emulation, qualifiedEnum
Children:
320e72a2, ab3a69c
Parents:
53bb8f1
Message:

Add ascription casts to future work

File:
1 edited

Unmodified
Removed
• ## doc/theses/aaron_moss_PhD/phd/resolution-heuristics.tex

 r53bb8f1 The main challenge to implement this approach in \CFACC{} is applying the implicit conversions generated by the resolution process in the code-generation for the thunk functions that \CFACC{} uses to pass type assertions to their requesting functions with the proper signatures. Though performance of the existing algorithms is promising, some further optimizations do present themselves. One \CFA{} feature that could be added to improve the ergonomics of overload selection is an \emph{ascription cast}; as discussed in Section~\ref{expr-cost-sec}, the semantics of the C cast operator are to choose the cheapest argument interpretation which is convertable to the target type, using the conversion cost as a tie-breaker. An ascription cast would reverse these priorities, choosing the argument interpretation with the cheapest conversion to the target type, only using interpretation cost to break ties\footnote{A possible stricter semantics would be to select the cheapest interpretation with a zero-cost conversion to the target type, reporting a compiler error otherwise.}. This would allow ascription casts to the desired return type to be used for overload selection: \begin{cfa} int f$$$_1$$$(int); int f$$$_2$$$(double); int g$$$_1$$$(int); double g$$$_2$$$(long); f((double)42);  $\C[4.5in]{// select f$$_2$$ by parameter cast}$ (as double)g(42); $\C[4.5in]{// select g$$_2$$ by return ascription cast}$ (double)g(42); $\C[4.5in]{// select g$$_1$$ NOT g$$_2$$ because of parameter conversion cost}$ \end{cfa} Though performance of the existing resolution algorithms is promising, some further optimizations do present themselves. The refined cost model discussed in Section~\ref{conv-cost-sec} is more expressive, but requires more than twice as many fields; it may be fruitful to investigate more tightly-packed in-memory representations of the cost-tuple, as well as comparison operations that require fewer instructions than a full lexicographic comparison. Integer or vector operations on a more-packed representation may prove effective, though dealing with the negative-valued $specialization$ field may require some effort.
Note: See TracChangeset for help on using the changeset viewer.