On 03-Jan-2001, Manuel M. T. Chakravarty <chak@cse.unsw.edu.au> wrote:
Fergus Henderson <fjh@cs.mu.oz.au> wrote,
Doing it in a separate tool will lose efficiency in some important cases. If the compiler is compiling via C, then it can insert inline C code directly in the generated code, and thus get inlining. But I think a separate tool would have to put the C code in a separate C file, which would prevent inlining.
This has some problematic consequences:
* Code which replies on this inlining would require any high-performance Haskell compiler to compile via C.
No code should rely upon this inlining for correctness. AFAIK none of it does. One of our backends that compiled via C had this sort of inlining turned off for quite some time.
* As I understand, these pragmas are supposed to support not only C. How about C++ code? Will there be a C++ backend for Mercury just to make this code efficient?
No. There's only (at most) one language per backend that can be inlined in this way. Otherwise you have to do your best. You can inline the C wrapper code that is used to call into C++, but that's about it. The inlining is not important for semantics, but it might be important for benchmarks ;-) -- Tyson Dowd # # Surreal humour isn't everyone's cup of fur. trd@cs.mu.oz.au # http://www.cs.mu.oz.au/~trd #