llvm dev - May 2015 - [LLVMdev] llvm cross compilation and simplescalar simulation for ARM

Hi, 

I want to explorer affection of compiler on low power. 
For the project background, I tend to process this work via LLVM, rather than
GCC. And the Target is ARM.

For this purpose, clang(3.2) + arm-gcc + simplescalar-arm(and panalyzer) seems
to be a good choice. But I encounter several problems in the processing of setup
the environment.

----------------------------------
1. Firstly, arm toolchain is built via ‘buildroot-2012.08’: arm-linux-gcc,  I
compile MiBench step by step or on one step as follows:
clang -emit-llvm —target=arm -O3 -c susan.c -o susan.bc
llc -march=arm -filetype=asm susan.bc -o susan.s
arm-linux-gcc -static -L/arm-toolchain/lib/path susan.s -lm -o susan.out
or:
clang -static -gcc-toolchain /arm-toolchain/path -target arm-linux
-sysroot=/arm-toolchain/sysroot/path susan.c -o susan.out -lm

but I encounter the problem about ‘uclibc’. There is no ‘_IO_getc’ in libc.a of
uclibc, but clang&llc compile ‘getc’ in C source to ‘_IO_getc’ in assembler.
I tried to use newer version of buildroot which support ‘glibc’ (like
'buildroot-2014.11'), but the newer version doesn’t support to set the
’Target ABI’ to ‘OABI’, someone says OABI rather EABI is necessary if want the
executable run on simplescalar. So I don’t know how to solve this issue.

----------------------------------
2. Then, I change the toolchain from ‘buildroot’ to ’Sourcery CodeBench’:
arm-none-linux-gnueabi-gcc, I compile ’susan’ in MiBench as the above commands.
I get the executable application (susan.out) successfully. That is to say, I can
cross compile arm application via clang/llc/arm-none-linux-gnueabi-gcc!!!
However, I get a fatal error when I run susan.out on simplescalar-arm:
fatal: non-specultative fault (2) detected @ XXXXXXX

I searched the reason via google, someone says that the toolchain is too new for
simplescalar-arm.
It seems this method is failure, as well.

----------------------------------
3. I tried several other arm-toolchains, such as arm-linux-gcc-4.4.3 from
FriendlyARM, arm-gcc-2.95.3 recommended by simplescalar-arm official, but I
encountered the similar problems as the above.

----------------------------------
4. I find a same issue in llvmdev maillist:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-September/053740.html
<http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-September/053740.html>
(And also some other similar topics via Google)
The topic is “clang cross compilation and SimpleScalar simulation”.
But there is no solution in the issue.


My Question is:
1. If I do compiler related low power experiment via llvm(3.2) + arm-gcc +
simplescalar-arm(and panalyzer), how could I setup the environment?? Does anyone
has  the experience and can give some instructions?
2. If I process the job via LLVM + ARM, but not simplescalar-arm, is there any
other simulator to run arm application?? The simulator should has a mature power
model.

Thanks
-Shiqiang





-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150507/b1ca896f/attachment.html>

> For this purpose, clang(3.2) + arm-gcc + simplescalar-arm(and panalyzer)
> seems to be a good choice.
3.2 is a very old release in LLVM terms. I doubt anyone here really
knows all the details about it any more. You'd be much better off
using the most recent stable release (3.6) or even trunk.
> but I encounter the problem about ‘uclibc’. There is no ‘_IO_getc’ in
libc.a of uclibc, but clang&llc compile ‘getc’ in C source to ‘_IO_getc’ in
assembler.
The current source doesn't seem to randomly create calls to _IO_getc.
My best guess here would be you're including headers from your host
platform (due to a misunderstood --sysroot), rather than the uclibc
ones.
> someone says OABI rather EABI is necessary if want the executable run on
simplescalar. So I don’t know how to solve this issue.
This is really worrying too: no-one uses OABI any more. It's virtually
untested on linux, as far as I know (though probably kept from
complete bit-rot by the fact that iOS uses a similar ABI).
> However, I get a fatal error when I run susan.out on simplescalar-arm:
> fatal: non-specultative fault (2) detected @ XXXXXXX
This could well happen if your simplescalar program isn't expecting
gnueabi (or any eabi) code.
> arm-gcc-2.95.3 recommended by simplescalar-arm official
That's a massive red flag. GCC 2.95 was released in 1999 (2.95.3 in
2001). Those versions are truly ancient; they were obsolete before
Clang was even a glint in Reid Spencer's eye (unfairly picking the
first clang commit -- it's all Reid's fault, QED).
> 1. If I do compiler related low power experiment via llvm(3.2) + arm-gcc +
simplescalar-arm(and panalyzer), how could I setup the environment?? Does anyone
has  the experience and can give some instructions?
I suspect you're in for a world of pain. Both simplescalar and
LLVM-3.2 appear to be too old to be viable these days, which means
you're probably going to have to hack on one or both code-bases to
have a hope of producing anything functional.

Tim.

I am sorry that I made a mistake in the last email: I choose llvm-3.4.2, not
llvm-3.2.
> My best guess here would be you're including headers from your host
> platform (due to a misunderstood --sysroot), rather than the uclibc
> ones.
You are right here, I add a ‘-I’ option in clang command, and compile the
application successfully:
clang -emit-llvm -I/my/toolchain/path/include -std=c89 —target=arm -O3 -c
susan.c -o susan.c
llc -march=arm -filetype=asm susan.bc -o susan.s
arm-linux-gcc -static susan.s -lm -o susan.out

Yeah, simplescalar is too old to as a simulator in low power research. However,
I cannot find another efficient simulator.
Fortunately, I make the whole environment work well so far. (I simply tested
’susan’ and ‘qsort’ in MiBench).

By the way, do u have any other suggestions to explorer low power options?(via
LLVM and arm-gcc, and any other simulator & power model)
Thanks!

-Shiqiang

> 在 2015年5月7日，10:46，Tim Northover <t.p.northover at gmail.com> 写道：
> 
>> For this purpose, clang(3.2) + arm-gcc + simplescalar-arm(and
panalyzer)
>> seems to be a good choice.
> 
> 3.2 is a very old release in LLVM terms. I doubt anyone here really
> knows all the details about it any more. You'd be much better off
> using the most recent stable release (3.6) or even trunk.
> 
>> but I encounter the problem about ‘uclibc’. There is no ‘_IO_getc’ in
libc.a of uclibc, but clang&llc compile ‘getc’ in C source to ‘_IO_getc’ in
assembler.
> 
> The current source doesn't seem to randomly create calls to _IO_getc.
> My best guess here would be you're including headers from your host
> platform (due to a misunderstood --sysroot), rather than the uclibc
> ones.
> 
>> someone says OABI rather EABI is necessary if want the executable run
on simplescalar. So I don’t know how to solve this issue.
> 
> This is really worrying too: no-one uses OABI any more. It's virtually
> untested on linux, as far as I know (though probably kept from
> complete bit-rot by the fact that iOS uses a similar ABI).
> 
>> However, I get a fatal error when I run susan.out on simplescalar-arm:
>> fatal: non-specultative fault (2) detected @ XXXXXXX
> 
> This could well happen if your simplescalar program isn't expecting
> gnueabi (or any eabi) code.
> 
>> arm-gcc-2.95.3 recommended by simplescalar-arm official
> 
> That's a massive red flag. GCC 2.95 was released in 1999 (2.95.3 in
> 2001). Those versions are truly ancient; they were obsolete before
> Clang was even a glint in Reid Spencer's eye (unfairly picking the
> first clang commit -- it's all Reid's fault, QED).
> 
>> 1. If I do compiler related low power experiment via llvm(3.2) +
arm-gcc + simplescalar-arm(and panalyzer), how could I setup the environment??
Does anyone has  the experience and can give some instructions?
> 
> I suspect you're in for a world of pain. Both simplescalar and
> LLVM-3.2 appear to be too old to be viable these days, which means
> you're probably going to have to hack on one or both code-bases to
> have a hope of producing anything functional.
> 
> Tim.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150508/c7048b19/attachment.html>