llvm dev - Sep 2011 - [LLVMdev] sunkaddr var names

When viewing generated IR code in a module I generated, I'm seeing
%sunkaddr??
IR variables, being created that I did not generate. What is the point of these
var names,
and implementations of their use  such as:

  %sunkaddr16 = sext i32 %25 to i64

  %sunkaddr15 = ptrtoint i8* %addr to i64
  %sunkaddr17 = mul i64 %sunkaddr16, 4
  %sunkaddr18 = add i64 %sunkaddr15, %sunkaddr17
  %sunkaddr19 = add i64 %sunkaddr18, 28
  %sunkaddr20 = inttoptr i64 %sunkaddr19 to i32*
  store i32 %27, i32* %sunkaddr20

I can guess sunkaddr means sunk address, and that the implementation is 
combining two pointers into a 64bit value but in a strange way; two bit shift 
of one pointer added to another along with added offset of 28. Except for the
value of the last constant offset addition, this pattern is repeated in my IR.
The
constants do however always have the 2 least significant bits clear. Is this
final
sunkaddr20 address special to the target platform, which is OS X 10.7.x?

Thanks for any clarification

Garrison

On Tue, Sep 6, 2011 at 10:42 AM, Garrison Venn <gvenn.cfe.dev at
gmail.com> wrote:
> When viewing generated IR code in a module I generated, I'm seeing
%sunkaddr??
> IR variables, being created that I did not generate. What is the point of
these var names,
> and implementations of their use  such as:
>
>  %sunkaddr16 = sext i32 %25 to i64
>
>  %sunkaddr15 = ptrtoint i8* %addr to i64
>  %sunkaddr17 = mul i64 %sunkaddr16, 4
>  %sunkaddr18 = add i64 %sunkaddr15, %sunkaddr17
>  %sunkaddr19 = add i64 %sunkaddr18, 28
>  %sunkaddr20 = inttoptr i64 %sunkaddr19 to i32*
>  store i32 %27, i32* %sunkaddr20
>
> I can guess sunkaddr means sunk address, and that the implementation is
> combining two pointers into a 64bit value but in a strange way; two bit
shift
> of one pointer added to another along with added offset of 28. Except for
the
> value of the last constant offset addition, this pattern is repeated in my
IR. The
> constants do however always have the 2 least significant bits clear. Is
this final
> sunkaddr20 address special to the target platform, which is OS X 10.7.x?
>
> Thanks for any clarification
CodeGenPrepare does some rather messy transformations to work around
the fact that isel can't see anything cross-block.  This is one of
those transformations; it's basically expanding out the equivalent of
a getelementptr instruction.

-Eli