a packed constant cannot be referenced in the arithmetic instruction?

%foo1 = constant <4 x float> <float 1.0, float 2.0, float 3.0, float 4.0>;

void %main() {
    %x = mul <4 x float> %foo1, %foo1
    ret void
}

llvm-as complained " Reference to an invalid definition: 'foo1' of
type '<4 x float>' ".

I searched all test script in llvm/test, and I found the only way to
use packed constant is:

%foo1 = uninitialized global <4 x float>;

void %main() {
    store <4 x float> <float 1.0, float 2.0, float 3.0, float 4.0>, <4
x float>* %foo1
    %l1 = load <4 x float>* %foo1
    %x = mul <4 x float> %l1, %l1
    ret void
}

(in "llvm/test/Feature/packed.ll")

Why?

%foo1 = constant <4 x float> <float 1.0, float 2.0, float 3.0, float 4.0>;
void %main() {
   %x = mul <4 x float> %foo1, %foo1
   ret void
}

llvm-as complained " Reference to an invalid definition: 'foo1' of
type '<4 x float>' ".

That sort of constant is an LLVM global variable which is marked as constant. To use this, you would use:

%foo1 = constant <4 x float> <float 1.0, float 2.0, float 3.0, float 4.0>;
void %main() {
    %foo1val = load <4 x float>* %foo1
    %x = mul <4 x float> %foo1val, %foo1val
    ret void
}

I searched all test script in llvm/test, and I found the only way to
use packed constant is:

%foo1 = uninitialized global <4 x float>;

void %main() {
   store <4 x float> <float 1.0, float 2.0, float 3.0, float 4.0>, <4
x float>* %foo1
   %l1 = load <4 x float>* %foo1
   %x = mul <4 x float> %l1, %l1
   ret void
}

(in "llvm/test/Feature/packed.ll")

Why?

You should be able to do this as well (What I think you're trying to do with your original testcase):

void %main() {
    %x = mul <4 x float> <float 1.0, float 2.0, float 3.0, float 4.0>,
                          <float 1.0, float 2.0, float 3.0, float 4.0>
    ret void
}

Note that support for packed types in not yet fully implemented. In particular, the only way to codegen them currently is through the use of the -lower-packed pass, which converts them to scalar operations. Obviously we want to eventually codegen them to altivec, SSE, VIS, etc, but we don't currently have support for them.

-Chris