On 12/05/2016 05:17 AM, Alex Bennée wrote:
>> + /* ??? Ideally we'd know what values are available for immediate AND.
>> + Assume that 8 bits are available, plus the special case of 16,
>> + so that we get ext8u, ext16u. */
>> + switch (len) {
>> + case 1 ... 8: case 16:
>> + tcg_gen_shri_i32(ret, arg, ofs);
>> + tcg_gen_andi_i32(ret, ret, (1u << len) - 1);
>> + break;
>> + default:
>> + tcg_gen_shli_i32(ret, arg, 32 - len - ofs);
>> + tcg_gen_shri_i32(ret, ret, 32 - len);
>> + break;
>> + }
>
> Hmm is this starting to make a case for backend specific optimisation
> passes which have a better idea of the code that can be generated or
> exposing a TCG_TARGET_HAS_8IMM_BITS or some such from the backend to the
> generators?
Thanks for the prod. In theory the information is already available.
tcg_target_const_match((1u << len) - 1, TCG_TYPE_I32,
&tcg_op_defs[INDEX_op_and_i32].args_ct[2]);
That's currently static in tcg.c, but that could be fixed.
There could well be a call for backend-specific passes. I've been thinking of
the problems surrounding constant generation and reverse-endian stores for a
while now, which also sort of fall into this category.
r~
