search for: g_uaddo

...o map to > when you do register bank select. > The register class could be "not allocatable” (see CCR in AArch64 for > instance). > Note, that if that class is unallocable, you’ll have to manage > manually any overlapping that could arise. > E.g., > s32 ..., s1 carry1 = G_UADDO > s32 ..., s1 carry2 = G_UADDO > s32 extended_carry1 = zext s1 carry1 <— carry1 will be destroyed by > the second G_UADDO, you’ll have to fix the schedule or copy the value > manually. > s32 extended_carry2 = zext s1 carry2 > icmp s32 extended_carry1, extended_carry2 So befor...

...y, if you’re not following that model, you’re in violation of that and that’s where problems arise (and thus D75086 to workaround them). This leads me to another question. What would the correct modelling look like for special registers that cannot be read/written, like a carry-bit register? The G_UADDO/UADDE instructions have an s1 carry and our target only supports reading this special register, but not writing to it (at least not directly and without doing some hacks). We found this especially hard to model, since GlobalISel doesn't really have a notion of special registers in generic i...

Hi Quentin, Hi Amara, I was following your discussion on D75086 regarding declaring types as legal even if they are smaller than the actual register class (e.g. s16 and gpr32). We are working on a backend which only has 32 and 64-bit registers and we recently had a problem regarding exactly this where we had to declare G_UNMERGE_VALUES and G_MERGE_VALUES with a smaller type of <s32 as