On Mon, Nov 21, 2016 at 5:45 PM, Johannes Berg
<johannes@xxxxxxxxxxxxxxxx> wrote:
> Yes, that'd make some sense. I have no idea how to pull it off though
I take a brief look.
It seems that you need to implement a symbol with ".expand" implement as
"expand_bswap", similar to "expand_constant_p".
Later in in "eval_init_table", just add one entry for __builtin_bswap.
eval_init_table[] = {
{ "__builtin_constant_p", &builtin_fn_type, MOD_TOPLEVEL, &constant_p_op },
{ "__builtin_safe_p", &builtin_fn_type, MOD_TOPLEVEL, &safe_p_op },
{ "__builtin_warning", &builtin_fn_type, MOD_TOPLEVEL, &warning_op },
{ "__builtin_expect", &builtin_fn_type, MOD_TOPLEVEL, &expect_op },
{ "__builtin_choose_expr", &builtin_fn_type, MOD_TOPLEVEL, &choose_op },
{ NULL, NULL, 0 }
};
As you can see in "expand_call", the cost of arguments is zero
if all arguments are constant.
The function "expand_symbol_call" even have the comment about expanding
the builtins there.
In side the "expand_bswap", it should abort if cost is not zero.
It means arguments are not constant, this expression can't
expand into a constant value.
Otherwise, expand_bswap should proceed to calculate the return
value of the bswap call and rewrite the call expression into a constant.
Some what similar to the "__builtin_constant_p".
I will see if I can hack up some thing very quick.
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
