similar to: [LLVMdev] Bytecode change

On Dec 6, 2006, at 10:44 AM, Andrew Lenharth wrote: > Currently, Structure layout is left to targets, which implement them > according to the ABI of that platform. While this is fine for most > structures, it makes packed structures very ugly. All fields in a > packed type must be converted to byte arrays with casts to access > fields, which bloats accesses and obsfucates the

Currently, Structure layout is left to targets, which implement them according to the ABI of that platform. While this is fine for most structures, it makes packed structures very ugly. All fields in a packed type must be converted to byte arrays with casts to access fields, which bloats accesses and obsfucates the types. First class support for packed types would clean up the generated code

On Thu, 2006-12-07 at 22:00 -0800, Chris Lattner wrote: > On Dec 6, 2006, at 10:44 AM, Andrew Lenharth wrote: > > > Currently, Structure layout is left to targets, which implement them > > according to the ABI of that platform. While this is fine for most > > structures, it makes packed structures very ugly. All fields in a > > packed type must be converted to byte

All, If you're not working on the CVS Head, you can skip this. I've just committed a long anticipated change to the Bytecode Reader: deleting over 700 lines of backwards compatibility code. This will make future changes easier to implement in the reader. Backwards compatibility for bytecode versions 0 through 4 has been eliminated. This means that bytecode generated by LLVM Versions 1.3

Hello Everyone. I'm going to break bytecode format a little bit. This is need to support function aliases. The corresponding patch was sent to llvm-commits for review (http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070416/047998.html). However, I tried to make things as much backward-compatible, as I can. Your bytecodes will be broken only if you're using module-wide

On 11/30/06, Andrew Lenharth <andrewl at lenharth.org> wrote: > The llvm_ostreams, which you take the address of go out of scope very > quickly, and are only stored by address in the bytecode writer, thus > the writers have a pointer to a stack allocated object they are to > write to. This crashes. The attached version leaks :-) It is a work around. If I understand correctly,

Hi Roman, On Tue, 2006-12-19 at 17:32 -0800, Roman Levenstein wrote: > Hi, > > I just updated my LLVM sources from CVS/HEAD and rebuilt them. And I > downloaded the GCC4 frontend from the 1.9 release. > > Now I cannot compile anything, since GCC frontend seems to produce BC > files that cannot be read by llvm-dis, llc and other utils. > > llvm-dis shows a following

LLVM 2.0 is done! Download it here: http://llvm.org/releases/ or view the release notes: http://llvm.org/releases/2.0/docs/ReleaseNotes.html LLVM 2.0 is a great release in many ways. It includes a wide range of new features, new optimizations, better codegen, and new targets. We were also able to signficantly revise several core aspects of the LLVM IR and design (such as the type system

Hi Reid, --- Reid Spencer <rspencer at reidspencer.com> wrote: > On Tue, 2006-12-19 at 17:32 -0800, Roman Levenstein wrote: > > But since the new llvm-dis cannot disassemble, I cannot use > > llvm-upgrade, since I need a way to produce an *.ll file. > > If you can't do as Bill suggested (get the latest llvm-gcc and > compile > it), you can use this approach:

On Tue, 29 Mar 2005, Andrew Lenharth wrote: > So Alpha and some other potential targets (amd64?) use structs for > va_list. This is very much at odds with the current instructions and > intrinsics. Yes, this is a serious issue. > And given that, can the 1.0 conversion code be dropped? Yes, 1.0 is dead. Assuming people have 1.1 (and removing the code for dealing with 1.0) or later

Hi Ariel, > can you say what was the reason to rename bytecode? I am still interesting in you forgot to send this to the mailing list, so I have (probably someone there knows better than I). I think the reason is that bitcode is bit-packed, i.e. you can have multiple pieces of information stored in one byte, so byte code was a misnomer. Ciao, Duncan. > > 2010/9/29 Duncan Sands

On Fri, 17 Sep 2004, Andrew Lenharth wrote: > > Hrm, I would much rather just have LLVM be a drop in replacement for a C > > compiler. As such, it should expose identical #defines to GCC. > > A drop in replacement for "a C compiler" is rather a different > requirement than a drop in replacement for GCC. If the goal is pure GCC > compatibility then sure,

So Alpha and some other potential targets (amd64?) use structs for va_list. This is very much at odds with the current instructions and intrinsics. So the question for the community is how much backwards compatibility should be maintained for vaargs? Essentially the behavior needs to be reverted to LLVM 1.0 semantics for vaarg instructions. Currently there is conversion code to convert the old

On Thursday 10 February 2005 21:47, Markus F.X.J. Oberhumer wrote: > In order to get more familiar with the llvm sources I've recently > decided to try to add support for the always_inline and noline function > attributes. I believe it is better to let the compiler decide when or not to inline a function. Most of the times a developer goes overboard with inlining and ends up with a

On 11/30/06, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > On 11/30/06, Andrew Lenharth <andrewl at lenharth.org> wrote: > > The llvm_ostreams, which you take the address of go out of scope very > > quickly, and are only stored by address in the bytecode writer, thus > > the writers have a pointer to a stack allocated object they are to > > write

All, Our plan in 2.0 for backwards compatibility with llvm-1.9 is to provide a translator for upgrading from 1.9 to 2.0 llvm assembly. The tool will be named llvm-upgrade and used something like this: llvm-1.9/bin/llvm-dis < 1.9.bc | llvm-2.0/bin/llvm-upgrade | llvm-2.0/bin/llvm-as -o 2.0.bc The 2.0 assembly and bytecode are going to be significantly different and this approach offers us a

DSA should be current against head, but poolalloc isn't. I've changed DSA a bit so it may not compile with poolalloc as is. I haven't had time to tackle updating poolalloc (either to head or to the dsa changes). If you want the version from the paper, try checking out llvm 1.8 or 1.9 and a dsa from around then. The dsa as used on the linux kernel and in the OS work is in a branch

Developers, As part of PR411, I have made several of the intrinsic functions non- overloaded. While the assembler and bytecode reader are backwards compatible, front-end writers should start using the non-overloaded versions of the intrinsics. The llvm-gcc has already been updated to generate the new intrinsic names. Other front-ends will start seeing warnings about the names of intrinsics that

All, Last night I removed compaction tables from the bytecode format (documentation change forthcoming). This was done for a few reasons. First, its very expensive in CPU time to process compaction tables 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

Haifeng He wrote: > I updated the latest "poolalloc" code and the problem seems to have been fixed. > However, I am still having problem of running "poolalloc". > > After compilation finished, there are several dynamic libraries > created (libpoolalloc_rt.so, libpoolalloc_fl_rt.so and > LLVMDataStructure.so). I was not sure which one I should use so I just