https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
--- Comment #63 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #62) > What the patch including incremental one currently does is: > 1) small _BitInt (on x86-64 N <= 64) - the BITINT_TYPEs are kept as is in > the IL > and expanded, they always have non-BLKmode (QI/HI/SI/DI) and are handled > like any > other INTEGER_TYPEs (except preserved in calls to ensure correct ABI > passing) > 2) middle _BitInt (on x86-64 N <= 128) - I keep in the IL just copy > operations and > casts between them and INTEGER_TYPE (TImode in this case), actual > arithmetics is > done on the INTEGER_TYPE > 3) large _BitInt (on x86-64 that will be <= 255) - the intent was using > BIT_FIELD_REFs/BIT_INSERT_EXPR to make the IL simple and perform stuff on > the > up to 4 limbs in this case in straight line code So these large _BitInt already have BLKmode? If so I'd suggest to initially handle them like the huge _BitInt code but "unrolled" and iterate on the code-gen later - I can have a look once one can play with the actual code and testcases. > 4) huge _BitInt (on x86-64 N > 255) use loops, VAR_DECL destination, > VCE+ARRAY_REF > on the sources, > dunno yet if I can get good code by making the VAR_DECL clobbered > immediately after > I load a SSA_NAME from it (whether out of SSA/expansion could then extend > the > lifetime of the VAR_DECL, or if I should have some pass do that, or the > bitint pass > figure out the last use and put clobber only after that, or even replace > the SSA_NAME > uses with accesses to VAR_DECL > > Anyway, I think I'll work now on the add/sub with carry now and continue on > _BitInt only after that.
