On Thu, Nov 24, 2016 at 08:56:45AM +0800, Christopher Li wrote: > On Thu, Nov 24, 2016 at 4:48 AM, Luc Van Oostenryck > <luc.vanoostenryck@xxxxxxxxx> wrote: > > There is a problem though, with non-constant args. > > Now the predeclarations of the 3 __builtin_bswap16/32/64 > > are gone, no more prototype and thus no more typing information. > > > > For example, if you call __builtin_bswap64() with an int argument, > > there is no way for the next steps to know the arg must first > > be 64 bit extended. Same for the result's type. > > That is a very good point. Need more work on that. > > The currently problem if I include the function prototype, the > function prototype symbol will over shadow the symbol contain > swap_op. We need to make sure the function prototype symbol > is the one loading with correct swap_op. Yes indeed. 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. 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). > Ideally, all the "__builtin_xxx" related stuff should be move to a > separate builtin.c. Right now the function prototype is in lib.c > The implementation is sprinkle around symbol.c, evaluation.c > and expand.c. It would be good, yes. Luc -- 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
