Displaying 20 results from an estimated 30000 matches similar to: "[LLVMdev] C Types -> LLVM Objects"
2005 Oct 31
0
[LLVMdev] C Types -> LLVM Objects
On Sun, 30 Oct 2005, Evan Jones wrote:
> I am implementing the support library for my toy Python implementation in C.
> Is there a recommended way to import types/functions defined in my C library
> as LLVM type objects into my compiler? I am currently doing this:
>
> - Create a "null" C file that references the important types
> - Load the bytecode of this file when
2005 Nov 02
1
[LLVMdev] Memory management and LLVM types
I am somewhat confused about how I should go about releasing LLVM
types. Some types are owned by a Module, and others I am not sure
about. Are there any general rules or guidelines that I should be aware
of? It appears to me that whenever I am passing a "new" object into a
container type like a module or basic block that the container owns the
object. Is that accurate? If this is
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 Nov 30
4
[LLVMdev] Trouble using llvm tools
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 something. Also, can you send the actual bytecode file itself?
Thanks!
-Chris
>
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 Oct 25
2
[LLVMdev] Some basic questions about LLVM version 1.8 bytecode format
<!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">
I generated LLVM bytecode for a "hello world!" program just to get the
basic bytecode structure. I have
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
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
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 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'
2006 Feb 27
0
[LLVMdev] Using llvm-gcc with a simple program and the '-c' option
The -c option tells llvm-gcc to build a bytecode file without linking
in the LLVM runtime library. This is similar to the -c option for
regular gcc, which you use to build multiple separate .o files that
you're going to link into a single executable. If you want to build
from a single source file, it's easiest just to compile without the -c
option. If you're building from
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
2007 Feb 23
2
[LLVMdev] bytecode reader assertion failure
I have a compiler transform that I have been working on that produces
bytecode that passes the verifier. However, when I try to read that
bytecode back in, I get the assertion failure below.
llvm::BytecodeReader::ParseConstantPoolValue(unsigned int):
Assertion `(!isa<Constant>(Result) ||
!cast<Constant>(Result)->isNullValue()) || !hasImplicitNull(TypeID) &&
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
2004 Jul 21
0
[LLVMdev] GC questions.
Ok, that makes sense :).
, Tobias
On Wed, 21 Jul 2004, Chris Lattner wrote:
> 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
2005 Oct 28
3
[LLVMdev] "Bound Methods" in LLVM Bytecode
Hello,
I have been thinking about efficient implementation of dynamically typed
languages in my spare time. Specifically, I'm working on a toy
implementation of a tiny piece of Python using LLVM as a native code
generating JIT. I've run into a bit of an issue, involving how Python
deals with method calls. I'm not sure how/if I can implement this in
LLVM. In Python, the following
2004 Aug 19
4
[LLVMdev] Can't get llvmg++ to work
I'm another new person to LLVM. I can't successfully compile and
execute a simple C++ program. The compiler seems to work, as it
produces a.out and a.out.bc files, but I get a whole bunch of warnings:
WARNING: Found global types that are not compatible:
"struct.std::messages<wchar_t>"* %_ZN9__gnu_cxx10messages_cE
[16 x sbyte]*
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