similar to: [LLVMdev] Virtual "components" for llvm-config

The only thing that comes to me off the top of my head is to look at the various LLVM tools and applications and see if there are common sets of libraries used by the tools. Ideally we'd want to "llvm-config --libs {toolname}" for each tool where {toolname} is replaced by the virtual component corresponding to the tool. That might be overkill, but if there are multiple tools that

On Mar 22, 2006, at 11:22 PM, Reid Spencer wrote: > In looking at tools, we should also look at the example programs > and the > projects such as Stacker. For example, it would be nice to have a > virtual component that includes the libraries necessary for an LLVM > front end translator (source -> llvm bytecode). It would also be nice > to have a virtual component that

Hi This llvm-config --libs engine bcreader scalaropts <http://llvm.org/cmds/llvm-config.html> in website http://llvm.org/cmds/llvm-config.html But actually bcreader components is not there anymore. The new name of it is bitreader. I thinks this webpage may need to update and also. If i do "llvm-config --help". It will also show wrong component name in examples g++

Hello (again)! I fixed most of the system and the following projects compile now: * Analysis * AsmParser * Bytecode * CBeckend * Codegen * ExecutionEngine * Support * System * TableGen * Target * Transforms * VMCore I would like to compile at least x86 target as well as Fibonacci example (to test if it really works). In order to do so, I may need some hints: 1) How to generate

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

On Thu, 2006-03-23 at 00:58 -0500, Eric Kidd wrote: > On Mar 22, 2006, at 11:22 PM, Reid Spencer wrote: > > LLVM back end target library (LLVM IR -> machine code). > > What would you include in each set? I dunno. You want me to actually think about this stuff? :) I'd have to derive the actual set of required libraries, but I'm lacking motivation for that task right

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

For everyone understand which code must be emitted to implement TLS, I will paste the code generated by gcc for a simple function: __thread int a = 1; int f(){ return a; } gcc teste.c -o teste.s -S -O2 (arm-linux-gnueabi): .global a .section .tdata,"awT",%progbits <== special section for tls symbols .align 2 .type a, %object

Suppose I had a program that would receive bitcode and do something with it other than run it, and for performance I this program is built Release-Asserts. Currently, illegal types are caught by the AsmParser and again by some assertions in Type.cpp. However, a .bc file could contain an illegal type like [5 x void] and without assertions enabled, this actually gets created in the IR. Also,

At 06:43 PM 8/20/2004, Chris Lattner wrote: >On Fri, 20 Aug 2004, Robert Mykland wrote: > > >In any case, both signed and unsigned 8-bit constants can be written out > > >in a single byte. Again, do you think it's worth special casing this > > >though? Considering that we handle 8-bit strings specially already, there > > >are not a ton of 8-bit

Reid Spencer, thank you for your quick responce, finally i got to my PC at home. You wrote: > Attached are three files: "valery.cpp" which contains your original, > "reid.cpp" which contains corrections to most of the FIXME items and > "diffs" which shows the differences between them. The differences > should be instructive on what to do. You were

On Sat, Jun 6, 2009 at 6:32 PM, Nick Lewycky<nicholas at mxc.ca> wrote: > Whose responsibility is it supposed to be to check types for legality? > The BCReader? Or perhaps the verifier? It's pretty easy to resolve using the rule "assertions should never trigger": if the bitcode reader triggers an assertion, it's a bug in the bitcode reader. -Eli

On Thu, 8 Jan 2004, Grant Gould wrote: Dear Mr. Gould, > Is there any documentation of the llvm bytecode format? I looked > around the website but didn't see any; did I miss some obvious > document? At this time, we do not have any documentation on the bytcode format. I believe one LLVM user was working on such a document at one time, but if so, it is not complete. One option

On Wed, 21 Jul 2004, Tobias Nurmiranta wrote: > > Hi, I'm thinking out loud, please give me some feedback. > > Regarding llvm.gcread and llvm.gcwrite, wouldn't it be nicer if they are > implemented as: > > llvm.gcread(sbyte** object, uint offset) > llvm.gcwrite(sbyte* data, sbyte** object, uint offset) > > Where you also have the offset into the object. In

Hey there, I'm relatively new to the llvm scene, and so far I'm liking it quite a bit. I'm a bit perplexed as to what llvm-gcc's role is in everything. I've used it to create .bc files for really simple functions and it seems to do quite well at that, but I've been trying to figure out how to take the output from llvm-gcc and actually use it in another program.

Yeah. We need to have more extra fields in the instruction. Fo example, during high-level synthesis, we must schedule an instruction to a certain control step (or cycle), and bind it to be execute on a certain functional unit, etc. Besides the in-memory exchange of the information, we also want on-disk exchange. That introduces the write-out/parse-in problem. Thanks ----- Original Message -----

That worked quite well. Thank you. One question as a follow up: is there a nice/standard way of including the pre-made bitcode chunks in with the binaries that are being created which read them? Bascially, I'd like to have the same functionality, but rather than having one or more .bc files running around which need to be read at runtime by an executable, moving that into the code

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

Hi, I've updated the Python LLVM bindings for LLVM 1.5 (attached). I also thought of setting up a CVS repository for this, but before I do that I thought I'd ask if you want to take the Python bindings to the main LLVM CVS? I noticed that the C language bindings would be maintained there. Changes in Python-LLVM: - Updated to match LLVM 1.5 API - Added Windows build support (created

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