search for: bcwriter

...machine code). What would you include in each set? > There are > probably a few other categories, for example utilities that only mess > with passes (e.g. opt, LLVM bc -> LLVM bc). In many of these cases, you can just ask for the components you need: $ llvm-config --libs bcreader bcwriter scalaropts I think this is pretty reasonable. Do you think we need to provide short aliases for all these combinations, or can we just let the user specify them manually? "Virtual" components are quite useful, though, when (a) the exact set of libraries needed varies by platform o...

...dynamic") that works in all situations. The other three models are optimizations of the first. So, I think we should start implementing the "general dynamic" model. I believe the roadmap is: 1. make LLVM understand "thread_local" keyword. (AsmParser, AsmWriter, BCReader, BCWriter) 2. make llvm-gcc emit "thread_local" keyword 3. implement "thread_local" in C backend (model independent) 3. implement "general dynamic" tls model for i386-linux-gnu 4. implement "general dynamic" tls model for arm-linux-gnueabi (this is more complex because...

...8th-bit because the memory failure rates were so high (think vacuum tubes). > Thus, (and I'm guessing here), you guys decided to treat char > strings as a special case to save space in the bytecode file. Actually, LLVM doesn't really treat character strings specially EXCEPT in the bcwriter and bcreader. There is no notion in LLVM of a "string", just primitive types and arrays of them. It is up to the front end compiler to define what it means by a "string". In the bytecode libraries of LLVM, we chose to interpret "[n x ubyte]" and "[n x sbyte]"...

...;Attached to this email you can find the diffs versus current CVS that makes >all the touched files compile under Microsoft Visual C 7.1 > >The following libs are now building: >vmcore, transformutils, transform, cwriter, lli-jit, executionengine, >selectiondag, modulosched, sched, bcwriter, datastructure, ipa > >Next patch will be the conversion of some C99 dynamic array to std::vector, >if nobody complains about it... ><< diff.txt >> > >--- >Paolo Invernizzi > >On Sep 7, 2004, at 11:31 PM, Chris Lattner wrote: > >>>for (BasicBlock:...

...f the most commonly used ASCII symbols are above 0x30. > > Thus, (and I'm guessing here), you guys decided to treat char > > strings as a special case to save space in the bytecode file. > >Actually, LLVM doesn't really treat character strings specially EXCEPT >in the bcwriter and bcreader. There is no notion in LLVM of a "string", >just primitive types and arrays of them. It is up to the front end >compiler to define what it means by a "string". In the bytecode >libraries of LLVM, we chose to interpret "[n x ubyte]" and "[n x...

...age? Yes, but you'd have to manually insert the debugging support information which would be tedious. You'd be better off doing something like writing a debug info insertion pass and applying it to the Module. This way you can use llvmAsmParser to get a module, apply the pass and then the bcwriter to create the bytecode with the debug info in it. Reid -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.llvm.org/pipermail/llvm-dev/a...

I forgot that lli was "special". It uses the "JIT" keywoard which means "figure out the right libraries to use for a JIT compiler and runtime". So, just add this, to tools/lli/Makefile: USEDLIBS := LLVMBCWriter That worked for me. Reid. On Thu, 2005-02-24 at 16:58, Patrick Meredith wrote: > Where do I add that line? Just putting it in the vanilla Makefile in > tools/lli doesn't work. > > ----- Original Message ----- > From: "Reid Spencer" <reid at x10sys.com> >...

Yikes, my tree must be more outdated than I thought. My library is still called bcwriter. Unfortunately when I add that line I get even more errors, seems like the only solution is going to be updating everything ;-) ----- Original Message ----- From: "Reid Spencer" <reid at x10sys.com> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent:...

...right now. > > > There are > > probably a few other categories, for example utilities that only mess > > with passes (e.g. opt, LLVM bc -> LLVM bc). > > In many of these cases, you can just ask for the components you need: > > $ llvm-config --libs bcreader bcwriter scalaropts > > I think this is pretty reasonable. Yup. > Do you think we need to provide > short aliases for all these combinations, or can we just let the user > specify them manually? I think just using the "long hand" is fine for now. If it becomes cumbersome and...

...bles for both reading and writing. Second, the maximum benefit we gained was about 7% (600K a 9Mb bytecode). In most cases its in the 1% range or actually makes the bytecode larger. Finally, as we prepare for the bitcode format, it helps us to simplify the existing bytecode format and the bcreader/bcwriter code. Compaction tables were a significant complexity in that code. Reid.

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 Fri, 3 Sep 2004, Paolo Invernizzi wrote: > I can confirm that both are compiled properly: Ok. > for (BasicBlock::iterator I = H->begin; isa<PHINode>(I); I++) { > PHINode *PN = cast<PHINode(I); > .... > } > > I'll make a patch for whatever solution do you prefer (this problem is > a showstopper for more than a dozen files...) I prefer this

Hi, This is regarding the backend for garbage collection. My problem might be related to some strange memory fault created by my frontend, but I'll try here to get some feedback. For some strange reason I get segmentation fault in process_pointer in semispace.c (I've implemented a small collector, hopefully :). The fault occurs when I do: printf("process_root[0x%p] = 0x%p\n",

...ituations. The > other three models are optimizations of the first. So, I think we > should start implementing the "general dynamic" model. > > I believe the roadmap is: > > 1. make LLVM understand "thread_local" keyword. (AsmParser, AsmWriter, > BCReader, BCWriter) > 2. make llvm-gcc emit "thread_local" keyword > 3. implement "thread_local" in C backend (model independent) > 3. implement "general dynamic" tls model for i386-linux-gnu > 4. implement "general dynamic" tls model for arm-linux-gnueabi (this &gt...

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

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

To ease portability headaches, I'd like to support several virtual "components" in llvm-config. Possibilities include: all: Include all LLVM libraries. backend: Include either a working native backend or cbackend. engine: Include a working subclass of ExecutionEngine, either the JIT or interpreter. You could, for example, get a typical set of JIT-related libs using:

...for a function if there are no >>entries. All my simple examples have empty compaction tables that use up >>8 bytes per function. This would save space. > >Hmm. That's not supposed to happen. Have you got a bytecode and source >file that produces this? The algorithm in bcwriter for deciding whether to >emit the compaction table is pretty complicated. It should avoid the >compaction table any time there's no advantage to it space wise. The >compaction table's *sole* purpose is to save bytecode space and its BAD if >it gets used incorrectly. It happ...

...re no > >>entries. All my simple examples have empty compaction tables that use up > >>8 bytes per function. This would save space. > > > >Hmm. That's not supposed to happen. Have you got a bytecode and source > >file that produces this? The algorithm in bcwriter for deciding whether to > >emit the compaction table is pretty complicated. It should avoid the > >compaction table any time there's no advantage to it space wise. The > >compaction table's *sole* purpose is to save bytecode space and its BAD if > >it gets used i...

...compaction table for a function if there are no > entries. All my simple examples have empty compaction tables that use > up 8 bytes per function. This would save space. Hmm. That's not supposed to happen. Have you got a bytecode and source file that produces this? The algorithm in bcwriter for deciding whether to emit the compaction table is pretty complicated. It should avoid the compaction table any time there's no advantage to it space wise. The compaction table's *sole* purpose is to save bytecode space and its BAD if it gets used incorrectly. > > I hope you fi...