[PATCH] Debug info: Teach the SDag type legalizer how to split up debug info for integer values that are split into a hi and lo part.

[Iain Sandoe]

As of now, for targets that do multiple-levels of splitting to legalise variables this patch isn't functional.

[e.g. enable debug on MSP430 (patch available if you want it) and try something like]


```
long lnot (long x) {
 return ~x;
}

```
c.f. 


```
long long qnot (long long x) {
  return ~x;
}

```
for the first case, the variable is correctly split into pieces.

for the second it is not.  
I've traced a bit through the legaliser code and ISTM that the reason for this is that the legalisation is done leaf-wise:


```
             PAIRA (p0, p1)
            /
 VAR => PAIR
            \
             PAIRB (p2, p3)

```
when p0,p1 are visited, the debug information is not present on the PAIRA - since that is only filled in when it is visited (subsequently, as we move from leaves leftwards).

====

Function arguments are not handled at all by this process (they are split elsewhere, for the present I am assuming that this is intended to be handled by a separate patch?)

================
Comment at: test/DebugInfo/X86/sdagsplit-1.ll:10
@@ +9,3 @@
+;      long long res = b+1;
+;      if ( a == b )
+;        return res;
----------------
dblaikie wrote:
> Some comments about what these bits of code are trying to demonstrate would be helpful.
> 
> Sometimes I find test cases easier to understand by using stubs to indicate which pieces I care about and why I care about them. (eg: if I need a variable to be 'used' I just have a sink function declared: "void sink(long long)" and call that - helps make it clear that I just want the variable to be used, not that I'm particularly interested in op== comparison, say)
> 
> In any case, it'd be helpful to understand what things this code is meant to demonstrate - probably apparent in the test case either by comment or self-documenting techniques like I described.
> 
> Given that you're just testing the location of 'res' - is there any reason you need the a and b parameters at all?
The original intention of the testcase was to demonstrate piece-wise splitting of the arguments as well as the temporary.

As of now the arguments are not handled (will comment on that separately)

in fact something as simple as:

```
long long flip ( long long x)  { 
 return ~x;
}

```
might be enough to show the required behaviour,

http://reviews.llvm.org/D4832