On Wed, Feb 1, 2012 at 5:22 PM, Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx> wrote: > And there could be more. For example specific attributes on the > declaration may affect the ABI for the call (think asmlinkage or good > old pascal calling conventions on old macos :-) > > Not something we absolutely need to sort out right now but another > reason why we really need to base the LLVM side definition based on the > declaration. Yes, that is what I am talking about too. Notice that insn->func is a pseudo not a symbol. Pseudo can be result from another expression. That is my suggestion in the counter RFC, put the full symbol type into pseudo->type. You should have access of that information. > > I'll try to toy a bit more this week-end see if the patches work for all > cases I can think of. We really have two different things (represented > by the two different hunks) which we might try to better factor: > > The case of a function call where we are after the declaration, and the > case of creating an llvm type containing a function pointer (which can > happen as part of the first one if an argument is a function pointer) > for which we are looking at the base_type. > > We should at least make it a single piece of code that takes a symbol > and shoots out a llvm ref. Do you mean take a pseudo then shoot out a llvm ref? The pseudo is the more general form, a pseudo can come from symbol node or expressions (function pointers). 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
