llvm dev - Feb 2013 - [LLVMdev] At which point application vs target machine type width splitting happens?

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 -print-after-all, I see that width splitting
happens between last LLVM IR pass and first DAG pass dump. Using
-view-* doesn't give insight either. Nor I was able to find any
adhoc rules related to addc instruction in MSP430InstrInfo.td .

So, it seems to be handled somewhere in target-independent code
generator, can someone give a pointer to the code (and docs on this
specific matter if any, because that's rather important machine-specific
optimization topic IMHO, if you step aside from 32bit world).


-- 
Best regards,
 Paul                          mailto:pmiscml at gmail.com

Hi Paul,

On Fri, Feb 22, 2013 at 12:08 PM, Paul Sokolovsky <pmiscml at gmail.com>
wrote:
> So, it seems to be handled somewhere in target-independent code
> generator, can someone give a pointer to the code (and docs on this
> specific matter if any, because that's rather important
machine-specific
> optimization topic IMHO, if you step aside from 32bit world).
The code you want is in lib/CodeGen/SelectionDAG/LegalizeTypes.cpp. I
think it happens between "-view-legalize-types-dags" and
"-view-dag-combine-lt-dags". Essentially, any type that doesn't
have a
valid register class associated to it gets lowered (by expanding in
this case) to operations on types that *do* have legal
register-classes.

Unfortunately it's not got much independent documentation.

Tim.

Hi Paul, this is done by the type legalizer, which lives in the files
   lib/CodeGen/SelectionDAG/Legalize*Types*

Ciao, Duncan.
> 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 -print-after-all, I see that width splitting
> happens between last LLVM IR pass and first DAG pass dump. Using
> -view-* doesn't give insight either. Nor I was able to find any
> adhoc rules related to addc instruction in MSP430InstrInfo.td .
>
> So, it seems to be handled somewhere in target-independent code
> generator, can someone give a pointer to the code (and docs on this
> specific matter if any, because that's rather important
machine-specific
> optimization topic IMHO, if you step aside from 32bit world).
>
>

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
instruction selection.

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

Hello,

On Fri, 22 Feb 2013 16:50:39 +0400
Anton Korobeynikov <anton at korobeynikov.info> wrote:
> 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
> instruction selection.
Thanks for all the replies! Taking the hints, here's more datailed
flow for the "%1 = add nsw i32 %b, %a" example if someone later will
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 artificial limits on
operatable width of integer types, for example, msp430 happily adds
i128 values (with awful optimization though, like spilling values having
backing store instead of rematerializing them).

To trace thru "expand" operations, undocumented (?) -debug switch can
be
passed to llc. 


-- 
Best regards,
 Paul                          mailto:pmiscml at gmail.com