llvm dev - Aug 2009 - [LLVMdev] Bug in optimization pass related to strcmp and bigendian back-ends

I thought the LLVM IR is target independent and that "llvm-gcc -c
-emit-llvm -O2" produces target independent code.

I'm working on a back-end and use llvm-gcc to first generate the bc file.
Afterwards I use llc including the new back-end to produce the assembler file.

-Timo

-----Ursprüngliche Nachricht-----
Von: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] Im
Auftrag von Eli Friedman
Gesendet: Dienstag, 11. August 2009 10:27
An: LLVM Developers Mailing List
Betreff: Re: [LLVMdev] Bug in optimization pass related to strcmp and bigendian
back-ends

On Tue, Aug 11, 2009 at 1:13 AM, Stripf,
Timo<Timo.Stripf at itiv.uni-karlsruhe.de> wrote:
> On little endian machines the code works correct but on big endian %lhsv
> must be compared against 73 << 8.
If llvm-gcc thinks it's compiling for a little-endian target, the
optimizers will assume the target is little-endian... what are you
trying to do?

-Eli
_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Stripf, Timo wrote:
> I thought the LLVM IR is target independent and that "llvm-gcc -c
-emit-llvm -O2" produces target independent code.
> 
> I'm working on a back-end and use llvm-gcc to first generate the bc
file. Afterwards I use llc including the new back-end to produce the assembler
file.
> 
> -Timo
LLVM IR is very target dependent. The IR knows about things like 
endian-ness, alignment, etc.

I'm currently building newlib for several LLVM targets and I create 
separate bitcode for each target. Each module has the target triple and 
target data string specific to the target.

Unfortunately you need an llvm-gcc for the target you want to support. M 
I think clang can generate code for multiple targets. Maybe you should 
try that.

-Rich

Hello
> Unfortunately you need an llvm-gcc for the target you want to support. M
> I think clang can generate code for multiple targets. Maybe you should
> try that.
Usually adding new target to clang is a matter of few lines of code.
Some more things were needed if your target uses, for example, complex
calling conventions (e.g. like x86_64), but this can be easily skipped
for the first time.

You might want to see how different targets are hooked into clang
(e.g. msp430, s390x, ppc, pic16, etc)

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

On Aug 11, 2009, at 3:04 AM, Richard Pennington <rich at pennware.com>  
wrote:
> Stripf, Timo wrote:
>> I thought the LLVM IR is target independent and that "llvm-gcc -c
-
>> emit-llvm -O2" produces target independent code.
>>
>> I'm working on a back-end and use llvm-gcc to first generate the bc
>> file. Afterwards I use llc including the new back-end to produce  
>> the assembler file.
>>
>> -Timo
>
> LLVM IR is very target dependent. The IR knows about things like
> endian-ness, alignment, etc.
More precisely, LLVM IR generated from C is very target dependent.  See
http://llvm.org/docs/FAQ.html#platformindependent
for details.

Dan

Stripf, Timo wrote:
> I thought the LLVM IR is target independent
Yes.

  and that "llvm-gcc -c -emit-llvm -O2" produces target independent
code.

No.
> I'm working on a back-end and use llvm-gcc to first generate the bc
file. Afterwards I use llc including the new back-end to produce the assembler
file.
LLVM IR contains a target-information line but is otherwise target 
independent. This does *not* mean that you can convert C to LLVM IR in a 
target independent way.

C code may contain "#ifdef __ppc__". Now what? Or how about
"switch (x)
{ case sizeof(int): ... }". This question is a FAQ: 
http://llvm.org/docs/FAQ.html#platformindependent

LLVM IR is portable in the sense that it will run the same on any 
platform. C is portable in the sense that you can detect things about 
the platform so you may correct for them. It turns out that these are 
two fundamentally incompatible paradigms.

Some LLVM optimizations take advantage of the information in the target 
info line which could change the behaviour of the program if your target 
system doesn't match the one described in the info line.

Nick

Alright thank you all for your help and information and sry for describing it as
a bug.

For a "fast" workaround I simple use llvm-gcc with -O0, modify the
endian information within the ll file and use opt to optimize the code. That way
also the debugging information is not removed and everything works atm fine for
a non-trivial application. Later I'll also modify the front-end to support
the back-end but atm I think this is easier.

Just out of curiosity, are there any plans/ideas to increase the platform
independence of optimization steps or the LLVM IR? It is clear that for C/C++
front-ends it is useless but maybe it is useful for other platform independent
front-ends like java. Maybe add some kind of is_big_endian function to express
"is_big_endian ? 30 : 30<<8" within the IR that is replaced
within the back-end.

-Timo

-----Ursprüngliche Nachricht-----
Von: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] Im
Auftrag von Nick Lewycky
Gesendet: Mittwoch, 12. August 2009 04:35
An: LLVM Developers Mailing List
Betreff: Re: [LLVMdev] Bug in optimization pass related to strcmp and bigendian
back-ends

Stripf, Timo wrote:
> I thought the LLVM IR is target independent
Yes.

  and that "llvm-gcc -c -emit-llvm -O2" produces target independent
code.

No.
> I'm working on a back-end and use llvm-gcc to first generate the bc
file. Afterwards I use llc including the new back-end to produce the assembler
file.
LLVM IR contains a target-information line but is otherwise target 
independent. This does *not* mean that you can convert C to LLVM IR in a 
target independent way.

C code may contain "#ifdef __ppc__". Now what? Or how about
"switch (x)
{ case sizeof(int): ... }". This question is a FAQ: 
http://llvm.org/docs/FAQ.html#platformindependent

LLVM IR is portable in the sense that it will run the same on any 
platform. C is portable in the sense that you can detect things about 
the platform so you may correct for them. It turns out that these are 
two fundamentally incompatible paradigms.

Some LLVM optimizations take advantage of the information in the target 
info line which could change the behaviour of the program if your target 
system doesn't match the one described in the info line.

Nick

_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev