similar to: [LLVMdev] recommendation books on code generation?

I don't think you need any special books. There is nothing complicated going on that is not in a basic compiler book. Mostly you have to understand how they implemented basic things in this framework. Knowing modern C++ (i.e. templates, overloading, etc...) and STL pretty well is more important than knowing about compiler theory in order to understand things. The documentation online

If you wanted to write a new register allocator, that would be a different story. Then you would do well to read the literature to try and understand about various schemes that have already been invented. No need to reinvent the wheel. Most people doing a port can figure things out by just using their brain and the documentation already at the LLVM web site; but like I said, a good solid

Hi, (taking the plunge) I believe it's the case that if one were an experienced compiler engineer before coming to LLVM it might be a different story to if one were getting up to speed on how compilers work by starting with LLVM (which sounds like it might be the case here). Certainly in looking at the LLVM code in areas I don't know about there is the undeniable fact that one is trying

On Jan 19, 2013, at 6:00 PM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: > On 1/19/2013 7:55 PM, Sean Silva wrote: >> >> Although SmallString is actually pretty inefficient, since it keeps >> the string data separate from the "vector" header. I believe libc++'s >> std::string actually reuses the pointers in the "vector header"

"David Tweed" <david.tweed at arm.com> writes: > I don't know of a book, but as a suggestion: is there anyone who's > teaching a course on compilers using LLVM who has the lecture notes > (or even better actual lectures) online? The LCC book (A Retargetable C Compiler: Design and Implementation [Addison-Wesley, 1995, ISBN 0805316701, ISBN-13 9780805316704]) has

hi, there are two arrays named DecoderTable32[] and DecoderTable16[] that has no reference to. any idea why they are there? does it make sense to remove them? (this is llvm 3.3) thanks, Jun -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130823/a95811fb/attachment.html>

On Sat, Aug 24, 2013 at 2:15 AM, Reed Kotler <rkotler at mips.com> wrote: > Hi Jun, > > Are you using the Mips compiler or working on it? > > yes, i am looking at its code to understand this architecture. thanks. Jun > > On 08/22/2013 11:12 PM, Jun Koi wrote: > >> hi, >> >> there are two arrays named DecoderTable32[] and DecoderTable16[] that

I've been told by one person that they're scheduled to give a very practical compiler university course using LLVM next year, so I was pretty sure that there must be several courses elsewhere in the world that have already been given. Looks like I was wrong about that. -----Original Message----- From: dag at cray.com [mailto:dag at cray.com] Sent: 03 April 2013 16:25 To: David Tweed Cc:

Something that might interest you is the SetVector, which as its name implies is both a set and a vector paired together. You get the advantage of doing set-like operations (search) on the set and vector-like operations (iteration, random access) on the vector, but at the cost of paying the price for both data structures when modifying the structure (and double the memory). This seems like it

Hi, Thanks a lot for the help! It seems that the SmallSetVector is the ADT I need (interface-wise). Is more efficient than llvm::UniqueVector? In my use case I have to insert a new element in the structure only if the element is unique. I hardly expect more than 32 elements. Do you think I gain a lot if I use the SmallSetVector instead of using SmallVector + slow searching on every

UniqueVector is an stl map coupled with an stl vector[1], which seems very undesirable for you. As far as SmallVector + slow search, I believe that is precisely what the implementation of SmallSet does until it has to grow, after which it uses an stl set[2]. If you're always staying within your small number, SmallSetVector would be wasteful as the SmallSet would itself also have a SmallVector.

On 07/16/2013 06:01 PM, Reed Kotler wrote: > The Eclipse indexer seems to get stuck in the Clang unittests/AST > In Eclipse you can tell it that a given directory is derived, and then it won't try and index it. Probably the more complex clang tests are too involved for the indexer. >>> Hope this helps :) >>> >>> Regards, >>> >>> Tilmann

On 1/19/2013 8:36 PM, Chris Lattner wrote: > > See: > http://llvm.org/docs/ProgrammersManual.html#picking-the-right-data-structure-for-a-task Were the "small n" characteristics the main motivation? Memory-wise, STL classes allow user-defined allocators, so use of things like memory pools should be relatively straightforward. Just wondering... :) -Krzysztof -- Qualcomm

Hi Reed, On Jul 17, 2013, at 3:19 AM, Reed Kotler <rkotler at mips.com> wrote: > On 07/16/2013 06:01 PM, Reed Kotler wrote: >> The Eclipse indexer seems to get stuck in the Clang unittests/AST >> > > In Eclipse you can tell it that a given directory is derived, and then it won't try and index it. > > Probably the more complex clang tests are too involved

Hi, I saw that Nick Lewycky removed the LLVM portable hash_map and hash_sets. My research group was relying on those classes. What replaces hash_map and hash_set? The LLVM implementation was very convenient as there is no equivalent in STL, and Microsoft's implementation had a different name, as does the C++ 0X implementation. Thanks. Tom Jablin

Hi Jun, Are you using the Mips compiler or working on it? Reed On 08/22/2013 11:12 PM, Jun Koi wrote: > hi, > > there are two arrays named DecoderTable32[] and DecoderTable16[] that > has no reference to. any idea why they are there? does it make sense to > remove them? > > (this is llvm 3.3) > > thanks, > Jun > > > > > >

Hi, As Christmas approaches rapidly I would like to get some suggestions for interesting compiler books, papers and other type of information that one can read the few slow days over Christmas. Any recommendations ? I have the dragon book, but it would be fun to read something on what is happening in modern compilers. /Fred

Hi Fredrik, On Tue, 2006-12-19 at 15:13 +0100, Fredrik Svensson wrote: > Hi, > > As Christmas approaches rapidly I would like to get some suggestions for > interesting compiler books, papers and other type of information that one > can read the few slow days over Christmas. > > Any recommendations ? I have the dragon book, but it would be fun to read > something on what

What do you mean by write my code properly? With the way it's written right now it is encoding writing out to a stream and decoding from that stream but i'd like to use VBR but when i try it my app fails. and also on a different note I've written some test apps where it recordes from the mic encodes decodes then playes but when i try streaming it over the internet it has long

We've pretty happy now with a patch that adds two wrappers around SmallVector that make it 1) more convenient to use and 2) will tend to mitigate misuse of SmallVector. We think it's ready for wider discussion: https://reviews.llvm.org/D90884 SVec<T> is a convenience alias for SmallVector<T, N> with N chosen automatically to keep its size under 64 Bytes (that heuristic is easy