Dear Eric, I'm picking up on the thread related to caller/caller side casting on Sparc, your patch to target/46208, your comments in http://gcc.gnu.org/ml/gcc-bugs/2010-10/msg02390.html and the ABI issues in the embedded context. To be compliant with the existing ABI, we clearly need to pass char and short values as reg-wide ints. With your (revised) patch for 46208, this is taken care of at the caller side only, meaning that the cast code is replicated at call sites. In the embedded world, where a lot of calls to small (usually leaf) functions use subword arguments, this becomes a severe penalty. It can be reduced in three main ways: * solution 1 (partial): by optimizing the generation of type promotion code, cf. your comments in http://gcc.gnu.org/ml/gcc-bugs/2010-10/msg02390.html * solution 2 (partial): by reviewing and optimizing the inlining settings to enable the inlining of very small functions (there's a lead in http://gcc.gnu.org/ml/gcc-help/2010-11/msg00170.html) * solution 3 (radical): by consciously creating an ABI which would be more friendly to the embedded world. Solution 1 could significantly reduce the per-call-site overhead, without eliminating it completely. As you point out, it will require work on the expand and emit code to make sure that in the end the compiler emits sensible sequences of insns at each call site. Solution 2 may lead to improvement, but only for (very) small functions. On the other hand it would benefit a much wider audience - at least the other embedded/embeddable GCC targets. Solution 3 is a holistic approach... As you put it in http://gcc.gnu.org/ml/gcc-help/2010-10/msg00394.html, after 15 yers it's hard to change the official "desktop"/"performance" ABI, but maybe it's time to take into account the new reality: Sparc is now deeply embeddable (and I mean deeply: it can run on the battery of a cellphone or even on the energy from an induction loop). This means that a new application field with new constraints appeared for Sparc, with code density and efficient RAM usage being the key to success (defined as making the system use less memory resources and consume less energy). A well designed "embedded Sparc" ABI would help a lot in this domain. Sure it will affect the complete development toolchain (compiler, binutils, debug), but properly designed it would truly give a boost to the Sparc architecture in the embedded area. Pragmatically: I'm ready to start on solution 1 and 2, in that order, and to help with recommendations for solution 3. Any suggestions and comments are highly welcome. Cheers, Zbigniew -- dr Zbigniew Chamski - Infrasoft IT Solutions ul. Oskara Kolberga 33, 09-407 PŁOCK, Poland mobile: +48 668 773 916, phone: +48 24 262 0166 NIP 526-286-69-21, REGON: 141082454
