https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
--- Comment #61 from rguenther at suse dot de <rguenther at suse dot de> --- On Mon, 5 Jun 2023, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989 > > --- Comment #60 from Jakub Jelinek <jakub at gcc dot gnu.org> --- > (In reply to Richard Biener from comment #59) > > Oh, so BITINT_TYPE is INTEGRAL_TYPE_P but not INTEGER_TYPE (I think we > > don't have any BLKmode integer types?). > > Yes. Some BITINT_TYPEs have BLKmode. > > > I think the intent was to > > restrict the operation on actual mode entities, BLKmode means memory > > where it isn't necessary to restrict things. So you could add > > a BLKmode exception here (but then for _BitInt<63> you will likely > > get DImode?) > > Sure, _BitInt<63> has DImode, _BitInt<127> has TImode if it is supported. > TYPE_MODE is set according to the rules for structures (so that it would help > with function_arg etc. implementation on some targets), so I think say OImode > for _BitInt<254> isn't impossible. > > > Can't you use a MEM_REF to extract limb-size INTEGER_TYPE from the > > _BitInt<> and then operate on those with BIT_FIELD_REF and BIT_INSERT_EXPR? > > Of course when the whole _BitInt<> is a SSA name MEM_REF won't work > > (but when you use ARRAY_REF/VIEW_CONVERT the same holds true) > > I wanted to avoid forcing the smaller _BitInt results into VAR_DECLs and only > do it > for the ones where I'd use loops (the huge category). > The plan for loops is to do 2 limbs per iteration initially, plus if there is > odd number of limbs or even with partial limb 1-2 limbs done after the loop. > So, the large > category where loop isn't used would be up to 3 full limbs or 3 full limbs + 1 > partial. So for the large case you are not using BIT_FIELD_REF on _BitInt<>? But for the small case like _BitInt<63> with DImode you want to do that and also the variables are likely in SSA form, right? How is endianess defined? Probably per limb? Consider unsigned _BitInt<16> a, b; unsigned _BitInt<32> c; c = ((_BitInt<32>)a << 16) | (_BitInt<32>)b; (not sure whether the cast are required). It's all difficult enough if you don't need to wrap your heads around padding. Note that followup optimization passes will refrain from touching the !type_has_mode_precision cases because of padding. So I think it would be good to work on full-limb precision for the actual operations. It should be possible to VIEW_CONVERT a _BitInt<63> to _BitInt<64>, aka VIEW_CONVERT to the modes precision bit-int variant here (or to the actual integer mode integer type which would be even better).
