search for: expandintres_addsub

Hello > I'm trying to understand how fitting source integer type width into > target machine register width happens. My reading on LLVM > codegeneration topics (few megabytes) so far didn't have this topic > mentioned explicitly. This is done during DAG Legalization phase. The operation is splitted into two (ADD + ADDC / ADDE). These DAG nodes are later matches during

...ll google for it: Source file is LegalizeIntegerTypes.cpp, DAGTypeLegalizer::ExpandIntegerResult(SDNode *N, unsigned ResNo). handles width splitting (which apparently in LLVM slang called "expanding" which I'm, as a novice, find confusing). For add/sub, this calls DAGTypeLegalizer::ExpandIntRes_ADDSUB(SDNode *N, SDValue &Lo, SDValue &Hi) which splits value operation into 2 equal by width parts. If original type is not power-of-2, it appears to be promoted first to power-of-2 (elsewhere). For longer values, the process of splitting applies recursively. There doesn't appear to be artif...

Hello, I'm trying to understand how fitting source integer type width into target machine register width happens. My reading on LLVM codegeneration topics (few megabytes) so far didn't have this topic mentioned explicitly. As an example, how %1 = add nsw i32 %b, %a gets compiled into msp430 (16bit CPU) assembly as: add.w r13, r15 addc.w r12, r14 Using -print-before-all

I'd think i1 would be the proper and correct choice for a carry flag for the generic instruction. I expect that would also make UADDO/USUBO redundant with ADDC/SUBC (which would seem a good outcome). You'd need to make sure the right thing happened when converting from ADDC's 1-bit carry in/out to X86ISD::AD[DC]'s EFLAGS i/o. Right now the conversion can get away with assuming