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.
