On Thu, Nov 24, 2016 at 9:31 AM, Luc Van Oostenryck <luc.vanoostenryck@xxxxxxxxx> wrote: > Maybe another approach is possible: > - note the fact that "stuff" (I intentionally don't want to use > "function") like __builtin_bswap*() behave like an operator > or a function in the mathematical sense: they only depend on > their args, have no side-effect, ... in others word they are "pure" > like in MOD_PURE. > - because they're pure they necessarily return constant value if given > constant args. This may be used early, the value itself is only needed > in later phases. I think that is exactly why __builtins_xxx exist. There is also pure function and inline function etc. I guess I will still call it a function rather than "stuff". > It may also not be a bad idea to have a specific instructions for these > (like a few others, I'm thinking to rotate), after all it's not without > reasons that common CPU archs have these as real instructions > (but this won't directly help our present problem). If the function is expanded at compile time. It does not matter what instruction it was used. It only matter when it need to emit as real instruction in the back end. The black end still have the flexibility to inline asm it. Agree, it does not help our current problem though. Chris -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
