llvm dev - Nov 2006 - [LLVMdev] Byte code portability (was Re: libstdc++ as bytecode, and compiling C++ to C)

Reid Spencer schrieb:
> Note that C and LLVM types are *not* the same things (despite the
> similar names). We are in the process of making this abundantly clear.
> The LLVM IR will soon use names like i8, i16, i32, and i64 (signless
> integer quantities of specific sizes, regardless of platform).
I had explicitly specified the size in the input code using a uint32_t
type, the resulting C code used short, which is smaller on my target
platform.

Philipp

Hi Philipp,

On Fri, 2006-11-24 at 20:09 +0100, Philipp Klaus Krause
wrote:
> Reid Spencer schrieb:
> 
> > Note that C and LLVM types are *not* the same things (despite the
> > similar names). We are in the process of making this abundantly clear.
> > The LLVM IR will soon use names like i8, i16, i32, and i64 (signless
> > integer quantities of specific sizes, regardless of platform).
> 
> I had explicitly specified the size in the input code using a uint32_t
> type, the resulting C code used short, which is smaller on my target
> platform.
One would think that it should result in a 32-bit unsigned type but its
hard to say without something concrete. Can you supply a small,
pre-processed example of some code that results in a CBE short for an
input C/C++ uint32_t ?
> 
> Philipp
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Reid Spencer schrieb:
> Hi Philipp,
> 
> On Fri, 2006-11-24 at 20:09 +0100, Philipp Klaus Krause wrote:
>> Reid Spencer schrieb:
>>
>>> Note that C and LLVM types are *not* the same things (despite the
>>> similar names). We are in the process of making this abundantly
clear.
>>> The LLVM IR will soon use names like i8, i16, i32, and i64
(signless
>>> integer quantities of specific sizes, regardless of platform).
>> I had explicitly specified the size in the input code using a uint32_t
>> type, the resulting C code used short, which is smaller on my target
>> platform.
> 
> One would think that it should result in a 32-bit unsigned type but its
> hard to say without something concrete. Can you supply a small,
> pre-processed example of some code that results in a CBE short for an
> input C/C++ uint32_t ?
Hmm the problem was a bit different. I just reproduced it.

I used this input file:

#include <stdint.h>

uint32_t test(uint32_t t)
{
	return(t + 42);
}

and got the following code:

unsigned test(unsigned ltmp_0_1) {
  return (ltmp_0_1 + 42u);
}

unsigned is 16 bit on my target platform.

Philipp

Hello, Philipp.
> unsigned is 16 bit on my target platform.
Could you please show LLVM bytecode?

-- 
With best regards, Anton Korobeynikov.

Faculty of Mathematics & Mechanics, Saint Petersburg State University.

Anton Korobeynikov schrieb:
> Hello, Philipp.
> 
>> unsigned is 16 bit on my target platform.
> Could you please show LLVM bytecode?
> 
I've attached the .bc file and the .c source and output files.
I compiled dusing llvm-gcc (not configured as cross-compiler though, so
that might be the problem).

Nevertheless I don't really see why portable source shouldn't be
translated into portable source.

Philipp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.bc
Type: application/octet-stream
Size: 127 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20061124/f96d954c/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.c
Type: text/x-csrc
Size: 69 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20061124/f96d954c/attachment.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test2.c
Type: text/x-csrc
Size: 2929 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20061124/f96d954c/attachment-0001.c>