From: David G. (JIRA) <ji...@co...> - 2008-10-31 21:58:12
|
[ http://jira.codehaus.org/browse/XTENLANG-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Grove updated XTENLANG-59: -------------------------------- Fix Version/s: (was: X10 1.7.1 - JVM Hosted) X10 1.7.2 - JVM Hosted > language support for guaranteed inlining > ---------------------------------------- > > Key: XTENLANG-59 > URL: http://jira.codehaus.org/browse/XTENLANG-59 > Project: X10 > Issue Type: New Feature > Components: X10 Compiler > Affects Versions: X10 1.7 - JVM hosted > Reporter: Bruce Lucas > Assignee: Nate Nystrom > Fix For: X10 1.7.2 - JVM Hosted > > > As we have experienced, and as our customers have told us, it can be difficult to achieve desired inlining of methods in practice if you depending on existing back-ends to do the inlining. > This is exacerbated by cumbersome and finicky mechanims, involving final classes, methods etc. and obtuse java command line arguments, to help encourage the JIT to inline. > Customers have expressed this as a requirement for macro preprocessing, but of course macros have semantic issues - macro invocations look much like function calls, but have very different semantics. > So instead would it be possible for the X10 compiler to do semantics-preserving inlining of methods and functions at the source code level? A method or function would be source-code inlinable if it's source code was available at compile time - either because it was defined in the same compilation unit, or because we provided a facility for the compiler to store source code (or equivalent) in the compiler output. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |