long double type on ARM

Project Infrastructure LLVM Dev List Archives
#1

Dear LLVM members.

I am compiling coreutils-7.4 package for ARM linux using LLVM 2.5 version.

When i compiled ‘od’ program in coreutils package using LLVM 2.5,
i could see the error message on llc processing.

llvm-gcc -emit-llvm ./od.c -c -o ./od.bc -other-options…
llc -march=arm ./od.bc -f -o ./od.s
llc: /home/jaykang10/HardDisk2/Projects/LLVM/src/llvm-2.5/lib/Target/TargetData.cpp:305: unsigned int llvm::TargetData::getAlignmentInfo(llvm::AlignTypeEnum, uint32_t, bool, const llvm::Type*) const: Assertion `AlignType == VECTOR_ALIGN && “Unknown alignment type!”’ failed.

The problem was that
when i converted ‘od’ source code to llvm bitcode, long double type of ‘od’ source code was changed to x86_fp80 type in llvm bitcode and then llc on ARM target was not support x86_fp80 type.

I think that long double type on ARM is 8 byte. (same as double type)

When we use llvm on ARM target,(or other target not support x86_fp80)
i think it might be better to convert long double type in C to double type in llvm bitcode on llvm-gcc or
treat x86_fp80 type in llvm bitcode as double type on llc.
(I wonder if we select the target at llvm-gcc build time)

I would like to know how to solve the above problem.

Thank you

Best regards,

Jin-Gu Kang

#2

Hi Jin-Gu Kang!
It are possible that the problem you are experiencing have already been
solved in the current llvm 2.6 release tree and the current svn trunk.
So try using llc from llvm 2.6 release branch or llvm pre2.7 svn trunk!

It would be helpful if you could open a bugreport for this issue and
attach the problematic od.bc since we need a testcase from the bitcode
that exposes the bug inorder to help you analyse and solve your problem.

Cheers
Xerxes

Jin Gu Kang skrev:

#3

Hi Xerxes!

Now, I tried to compile 'od' program's bitcode using llc in llvm 2.6 release.
but there was same error as before.

To avoid this problem,
I modified a little bit code in $llvm_src/lib/Bitcode/Reader/BitcodeReader.cpp file

bool BitcodeReader::ParseTypeTable()
{
....
    switch (Stream.ReadRecord(Code, Record)) {
....
    case bitc::TYPE_CODE_X86_FP80: // X86_FP80
       if target is arm
         ResultTy = Type::DoubleTy;
       else
         ResultTy = Type::X86_FP80Ty;
....
}

I will send the bugreport for this problem with 'od.bc' file attatchment.

Thank you

Best regards,

Jin-Gu kang

#4

Unlike llvm itself, llvm-gcc needs to be configured for a particular target architecture. It looks like you’re using a copy of llvm-gcc that was built to generate x86 code.

#5

That would certainly do it. LLVM IR is not target-independent.

-Jim

#6

Hi Bob!

I could not find llvm file for ARM target in llvm-gcc 4.2 front end source code.

$llvm-gcc-src/gcc/config.gcc file

alpha*--)
cpu_type=alpha
need_64bit_hwint=yes

LLVM LOCAL begin

out_cxx_file=alpha/llvm-alpha.cpp

LLVM LOCAL end

;;
…
arm*--)
cpu_type=arm
extra_headers=“mmintrin.h”
;;
…
i[34567]86--)
cpu_type=i386

LLVM LOCAL begin

out_cxx_file=i386/llvm-i386.cpp

LLVM LOCAL end

APPLE LOCAL begin 5612787 mainline sse4

extra_headers=“mmintrin.h mm3dnow.h xmmintrin.h emmintrin.h
pmmintrin.h tmmintrin.h ammintrin.h smmintrin.h
nmmintrin.h”

(out_cxx_file variable is empty for ARM target)

I wonder if llvm-gcc 4.2 front-end support bitcode conversion for ARM target.

Thank you.

Best regards,

Jin-Gu Kang

#7

That is from 2.5, and just because there is nothing special listed in config.gcc does not mean it doesn’t work. For 2.5, the ARM port of llvm-gcc did not require a separate llvm-arm.cpp source file, so nothing needed to be added to config.gcc. It worked fine as far as I know.

For 2.6, you will see that there are some ARM-related changes to config.gcc in llvm-gcc.

#8

Until now, I didn’t know that llvm-gcc is target dependent.
and I could see the ARM-related changes to config.gcc in llvm-gcc for 2.6 ver.

I appreciate your kindly help.

Thank you.

Best regards,
Jin-Gu Kang