Displaying 20 results from an estimated 20000 matches similar to: "[LLVMdev] Some basic questions about LLVM version 1.8 bytecode format"
2006 Oct 26
0
[LLVMdev] Some basic questions about LLVM version 1.8 bytecode format
Hi Robert,
On Wed, 2006-10-25 at 16:00 -0600, Robert Mykland wrote:
> I generated LLVM bytecode for a "hello world!" program just to get the
> basic bytecode structure. I have a few questions about the global
> info module and the global constants module where there have
> apparently been changes since 1.4.
Okay.
> I would be happy to collect these differences and do
2006 Nov 16
0
[LLVMdev] Question about functions/bytecodes: external linkage
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
So I'm going through this super-easy example of a bytecode file along
the lines of "Hello World!"
2006 Nov 06
3
[LLVMdev] Problems building cfrontend 4 source on SUSE 10.1
I was having video problems, so upgraded my Linux box from SUSE 9.3,
where LLVM frontend 4 source built fine, to SUSE 10.1, where I got the
error message:
../../llvm-gcc4-1.8-source/gcc/libgcc2.c:541: internal compiler error:
Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://llvm.org/bugs> for instructions.
This version of SUSE
2003 Aug 26
1
[LLVMdev] Question: Bytecode Representation of Type Definitions Table
Distinguished LLVM Creators,
I've been looking through the bytecode representation of the type
definition table and had a few questions about it. There's an enum in
Types.h that defines all bytecodes that represent the primitive types and a
few other necessary things:
0 = 0x00 = Void
1 = 0x01 = Bool
2 = 0x02 = UByte
3 = 0x03 = SByte
4 = 0x04 = UShort (16 bits)
5 = 0x05 =
2004 Nov 30
0
[LLVMdev] Trouble using llvm tools
On Tue, 2004-11-30 at 08:58, Chris Lattner wrote:
> On Tue, 30 Nov 2004, Tanu Sharma wrote:
>
> > I have trouble using the llvm tools.Some of the errors are :
> >
> > $ llvm-dis prog.bc
> > $ llvm-dis: Invalid Top Level Block Length! Type:1, Size:456 (Vers=0, Pos=12)
>
> Can you explain how you generated this bytecode file? It looks corrupted
> or
2006 Nov 06
1
[LLVMdev] Problems building cfrontend 4 source on SUSE 10.1
Hi Robert,
Please make sure that you:
1. Completely rebuild LLVM (make clean; make reconfigure; make
tools-only)
2. Completely rebuild llvm-gcc (wipe out the build dir with rm -rf,
configure llvm-gcc
and rebuild it)
If you've done that, then please enter the debugger and get a stack
trace for us.
You will need to:
1. Capture the xgcc compile command that failed
2. Run that command
2007 Mar 06
6
[LLVMdev] alloca & store generation
I am writing a transformation that needs to add a call to a function F()
at the beginning of main() with the addresses of argc and argv as
parameters to F(). However, the bytecode file I'm transforming has not
allocated space on the stack for argc and argv. So, I developed my
transformation to change main() from:
-----
int main(int %argc, sbyte** %argv){
entry:
...
// some use of
2007 Mar 06
0
[LLVMdev] alloca & store generation
After looking at this problem longer, I believe that there is something
wrong with the disassembler. When I run my transformation and then
disassemble the output, I get bytecode that looks like:
-----
int %main(int %argc, sbyte** %argv) {
entry:
alloca int ; <int*>:0 [#uses=3]
alloca sbyte** ; <sbyte***>:0 [#uses=3]
store int %argc,
2004 Aug 24
4
[LLVMdev] More Encoding Ideas
On Mon, 2004-08-23 at 19:46, Robert Mykland wrote:
> At 06:43 PM 8/20/2004, Chris Lattner wrote:
> >I don't understand what you're getting at here. You can change char to
> >default to unsigned right now with llvm-gcc -funsigned-char. I don't
> >understand how that would change anything to be more useful though.
>
> Well, in the old days, char strings were
2004 Aug 26
0
[LLVMdev] More Encoding Ideas
At 09:37 PM 8/23/2004, you wrote:
>On Mon, 2004-08-23 at 19:46, Robert Mykland wrote:
> > At 06:43 PM 8/20/2004, Chris Lattner wrote:
> > >I don't understand what you're getting at here. You can change char to
> > >default to unsigned right now with llvm-gcc -funsigned-char. I don't
> > >understand how that would change anything to be more useful
2004 Aug 20
4
[LLVMdev] More Encoding Ideas
Dear Chris and Reid:
Some other random ideas I've had as I've been sifting through the new
bytecode format. Please let me know what you think.
1) ANSI C allows for char to default to unsigned char. This is I guess not
how it normally is in GCC. If char defaulted to unsigned char several
things would be possible. Single char constants that are defined would be
almost always stored
2004 Apr 14
5
[LLVMdev] Linking strncpy
Chris,
I'm fine with using JIT, but I'm trying to understand this problem:
1. My LLVM program does not produce correct results
2. Using llvm-dis, I disassemble the bytecode to C
3. I recompile using GCC and the program _works correctly_.
The only odd thing is when I recompile with GCC, I see these messages:
pal3.c:195: warning: conflicting types for built-in function `strcmp'
2004 Apr 14
0
[LLVMdev] Linking strncpy
The only thing I can think of is that string.h is being #included and
has different signatures for memcpy and strncpy. Possibly "char" is not
signed on your machine (very unusual) or some of the parameters are
declared as "const".
Reid.
On Wed, 2004-04-14 at 18:19, Eric Zimmerman wrote:
> Chris,
>
> I'm fine with using JIT, but I'm trying to understand this
2004 Apr 14
1
[LLVMdev] Linking strncpy
Hi,
I'm working on a CS326 compiler project, and I'm having some problems
using string functions. Some LLVM programs produced are either
aborting or giving incorrect results; however, if I disassemble the
LLVM bytecode and recompile with GCC, everything works fine.
I encountered the following error when running lli with
'-force-interpreter' option:
"Tried to execute an
2006 Nov 06
2
[LLVMdev] Problems building cfrontend 4 source on SUSE 10.1
Hi Robert,
On Mon, 2006-11-06 at 12:45 -0800, Robert Mykland wrote:
> Reid,
>
> Here's the backtrace you asked for:
>
> (gdb) bt
> #0 0x0862d65c in llvm::LiveVariables::runOnMachineFunction ()
Hmm, this is a little strange. Your LLVM build is non-debug (there's no
line numbers or arguments in any of the llvm related calls). However,
your llvm-gcc build seems to have
2004 Aug 20
0
[LLVMdev] More Encoding Ideas
Robert Mykland wrote:
> Dear Chris and Reid:
Hi Robert.
>
> Some other random ideas I've had as I've been sifting through the new
> bytecode format. Please let me know what you think.
>
> 1) ANSI C allows for char to default to unsigned char. This is I guess
> not how it normally is in GCC. If char defaulted to unsigned char
> several things would be
2006 Dec 21
1
[LLVMdev] lli, llvm-ld and runtime libraries
Hello again,
I'm exploring llvm's intermediary representation with this code:
////////////////////////////////////
%.LC0 = internal constant [13 x sbyte] c"hello world\0A\00"
declare int %puts(sbyte*)
implementation
int %main() {
%cast210 = getelementptr [13 x sbyte]* %.LC0, long 0, long 0;
call int %puts(sbyte* %cast210)
ret int 0
}
2003 Dec 22
1
[LLVMdev] How to explain?
hi,
I want to know what is exact meaning in the following code.
target endian--
%struct..TorRec--
%struct.TorRec--
implementation--
;<sbyte>[#uses=1/0]--
how to explain them in details?
Does anyone give me a guide?
thanks
yueqiang
--------------------------------------------------------------
target endian = little
target pointersize = 32
%struct..TorRec = type { int, void ()* }
2003 Dec 22
2
[LLVMdev] hello.bc & binary code
hi,
I try to build hello.cpp using both llvmg++ and GNU g++,
the generate llvm bytecode's size is about 960K,
and the size of binary code generated by g++ is only 13K.
Could anyone explain the difference between the two result?
BWT:
I rebuild the cfrontend in RH linux9.0, but when I build the hello.cpp
the llvmG++ reports warnings too, it shows:
-----------------------------
[yue at RH9
2004 Jul 21
2
[LLVMdev] GC questions.
On Wed, 21 Jul 2004, Tobias Nurmiranta wrote:
> > void *llvm_gc_read(void *ObjPtr, void **FieldPtr) {
> > return *FieldPtr;
> > }
>
> Hm, but doesn't FieldPtr need to be calculated target-specific in those
> cases?
For the field pointer, one could use the getelementptr instruction:
%pairty = { sbyte, sbyte, int* }
%pairPtr = ...
%fieldptr = getelementptr