[sparcv9] null often spilled to constant pool

[llvmbot]

Bugzilla Link	368
Resolution	FIXED
Resolved on	Feb 22, 2010 12:54
Version	1.2
OS	Solaris
Reporter	LLVM Bugzilla Contributor

Extended Description

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

[lattner]

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

[llvmbot]

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.

[llvmbot]

I'm testing out a patch for this.

[lattner]

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

-Chris

[llvmbot]

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