I have noticed that the 64-bit constant pointer null is often spilled to the
constant pool in the sparcv9 backend, requiring a 7-instruction sequence to
load it out of the constant pool. This is a pretty serious pessimization. For
an example of this behavior, try running llc -print-machineinstrs on the
following code:

implementation

void %foobar (sbyte* %arg) {
  ret void
}

void %caller () {
  call void %foobar (sbyte* null)
  ret void
}

For %caller, SunPRO cc with -O on the C-backend code produces the following
(ignoring prolog/epilog instrs):

/* 0x0004        */     or  %g0,0,%o0
/* 0x0008        */     call    foobar  ! params =  %o0 ! Result =  ! (tail call)

llc produces the following:

    sethi   %hh(.CPI_caller_0), %o1
    sethi   %lm(.CPI_caller_0), %o0
    or  %o1, %hm(.CPI_caller_0), %o1
    sllx    %o1, 32, %o1
    or  %o0, %o1, %o0
    or  %o0, %lo(.CPI_caller_0), %o0
    ldx [%o0+0], %o0
    call    foobar

.CPI_caller_0:
    .xword  0

Hrm, why would it even go to the constant pool?  Doesn't the sparc efficiently 
handle small integers?  Or maybe it's just because it's a pointer.

-Chris

I think it's because SparcV9InstrInfo::CreateCodeToLoadConst() calls
ConvertConstantToIntType() to try to turn a constant into an integer
that it can load, but ConvertConstantToIntType() doesn't know about
ConstantPointerNulls, so it returns with isValid=false, and
CreateCodeToLoadConst() falls back on its default behavior of spilling
the constant into the constant pool and emitting the gross sethi-or-
sllx-ldx sequence.

I suspect the right thing to do is teach ConvertConstantToIntType()
about ConstantPointerNull.

I'm testing out a patch for this.

I think you're right.  I'm having bad flashbacks about that method now.

-Chris

http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20040607/015154.html

With llc, we now get the following  MUCH more reasonable code for the testcase:

        add     %g0, 0, %o0
        call    foobar