"H.J. Lu" <hjl.to...@gmail.com> writes: > On Fri, Apr 29, 2016 at 5:30 AM, Richard Sandiford > <richard.sandif...@arm.com> wrote: >> Following on from the comparison patch, I think it makes sense to >> support << and >> for offset_int (int128_t) and widest_int (intNNN_t), >> with >> being arithmetic shift. It doesn't make sense to use >> logical right shift on a potentially negative offset_int, since >> the precision of 128 bits has no meaning on the target. >> >> Tested on x86_64-linux-gnu and aarch64-linux-gnu. OK to install? >> >> Thanks, >> Richard >> >> >> gcc/ >> * wide-int.h: Update offset_int and widest_int documentation. >> (WI_SIGNED_SHIFT_RESULT): New macro. >> (wi::binary_shift): Define signed_shift_result_type for >> shifts on offset_int- and widest_int-like types. >> (generic_wide_int): Support <<= and >>= if << and >> are supported. >> * tree.h (int_bit_position): Use shift operators instead of wi:: >> shifts. >> * alias.c (adjust_offset_for_component_ref): Likewise. >> * expr.c (get_inner_reference): Likewise. >> * fold-const.c (fold_comparison): Likewise. >> * gimple-fold.c (fold_nonarray_ctor_reference): Likewise. >> * gimple-ssa-strength-reduction.c (restructure_reference): Likewise. >> * tree-dfa.c (get_ref_base_and_extent): Likewise. >> * tree-ssa-alias.c (indirect_ref_may_alias_decl_p): Likewise. >> (stmt_kills_ref_p): Likewise. >> * tree-ssa-ccp.c (bit_value_binop_1): Likewise. >> * tree-ssa-math-opts.c (find_bswap_or_nop_load): Likewise. >> * tree-ssa-sccvn.c (copy_reference_ops_from_ref): Likewise. >> (ao_ref_init_from_vn_reference): Likewise. >> >> gcc/cp/ >> * init.c (build_new_1): Use shift operators instead of wi:: shifts. > > Can you also update change_zero_ext in combine.c: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70687 > > It should use wide_int << instead of HOST_WIDE_INT <<< to > support __int128.
The patch doesn't add wide_int shift operators since wide_ints have no sign. You need to use wi:: shift routines for them instead. However, there's already a wi::mask function for creating this kind of value directly. Like you say, the PR is about converting other code to use wi::, which is very different from what this patch is doing. I'll take the PR anyway though. Hope to post a patch on Wednesday. It also looks like the code is missing a check that the ZERO_EXTEND mode is scalar, since the transformation would be incorrect for vectors. Thanks, Richard
