search for: llvmnote

Hi all, For anyone interested, I posted two new ideas for changes to the LLVM IR. The first is basically a cleanup, the second is a major new feature: Eliminating the 'Void' Type: http://nondot.org/sabre/LLVMNotes/EliminatingVoid.txt Aggregates as First Class Values: http://nondot.org/sabre/LLVMNotes/FirstClassAggregates.txt Thanks to Dan Gohman for convincing me that aggregates as first class values is really possible, I think it is a great idea. -Chris

Hi Chris, > Eliminating the 'Void' Type: > http://nondot.org/sabre/LLVMNotes/EliminatingVoid.txt might not some ABI's require some special stuff when returning a struct, regardless of whether the struct is empty or not? If so this might add a cost if you use {} for void. Also, there are an infinite number of different ways of returning void: return {} or {{}} or {{{...

...g an existing value. Chris Lattner wrote: > Hi all, > > For anyone interested, I posted two new ideas for changes to the LLVM > IR. The first is basically a cleanup, the second is a major new > feature: > > Eliminating the 'Void' Type: > http://nondot.org/sabre/LLVMNotes/EliminatingVoid.txt > > Aggregates as First Class Values: > http://nondot.org/sabre/LLVMNotes/FirstClassAggregates.txt > > Thanks to Dan Gohman for convincing me that aggregates as first class > values is really possible, I think it is a great idea. > > -Chris > ______...

Chris Lattner wrote: > Aggregates as First Class Values: > http://nondot.org/sabre/LLVMNotes/FirstClassAggregates.txt > Thinking more about this...I kinda wish it was available right *now*, because I sure could use it. I've been working on functions returning structures today, and in the current IR I basically have two choices: Either return the struct using multiple return v...

Hi Talin, On May 5, 2008, at 1:13 AM, Talin wrote: > Chris Lattner wrote: >> Aggregates as First Class Values: >> http://nondot.org/sabre/LLVMNotes/FirstClassAggregates.txt >> > Thinking more about this...I kinda wish it was available right *now*, > because I sure could use it. I've been working on functions returning > structures today, and in the current IR I basically have two choices: > Either return the struct using...

...iled enough for internal clients. > > Anyway, in short, I think that we should unify the variety of code we have to deal with this stuff into a new TargetSpec class.   I don't have any short-term plan to implement this, but I wrote up some of my thoughts here: > http://nondot.org/sabre/LLVMNotes/TargetSpec.txt > > Remember that this isn't intended to be something users deal with, it's just an internal implementation detail of the compiler, debugger, nm implementation, etc. Bitcode currently does not carry enough options information to handle LTO. For example, if you use -O1...

On 02/23/11 02:46, Chris Lattner wrote: [...] > Remember that this isn't intended to be something users deal with, it's just an internal implementation detail of the compiler, debugger, nm implementation, etc. Can I put in a plea to have as much of LLVM as possible *not* require knowledge of a single, specific architecture to work? I have various things I would like to do that work on

On 23/02/11 19:26, Chris Lattner wrote: [...] > This request is completely orthogonal to the proposal. If you generate target independent LLVM IR, you don't have to put a triple into the IR. This isn't going to change. Unfortunately clang doesn't appear to be aware of this. It's forcing me to specify a triple (or at least, I haven't discovered a way of generating

Chris Lattner wrote: > On Apr 27, 2008, at 10:58 AM, Talin wrote: > >> I would certainly make use of this in my frontend. >> >> I suggest the names "getfield" and "setfield" for the two operations, >> > > I agree that 'get/insertvalue' are pretty generic, and am welcome to > suggestions. Get/set *field* imply that this applies

Hi, > Aggregates as First Class Values: it seems to me that having this would make the byval parameter attribute partly obsolete? Will there be semantic differences between passing a struct directly and a pointer to a struct byval? I can see that byval can be used on pointers to other things, but is that really useful? I can't see any use for compiling C code, are there other languages

On Wed, 7 May 2008, Matthijs Kooijman wrote: >> Aggregates as First Class Values: > it seems to me that having this would make the byval parameter attribute > partly obsolete? Will there be semantic differences between passing a struct > directly and a pointer to a struct byval? > > I can see that byval can be used on pointers to other things, but is that > really useful? I

> Byval and passing a first class aggregate have the same semantics. > However, byval is very efficient for large aggregates and first-class > aggregates is efficient for small ones. I was making the assumption that having the same semantics actually means being equivalent and thus resulting in the same generated code. Since, AFAICS, the LLVM IR mainly conveys semantics, what do both

On Apr 27, 2008, at 10:58 AM, Talin wrote: > I would certainly make use of this in my frontend. > > I suggest the names "getfield" and "setfield" for the two operations, > I agree that 'get/insertvalue' are pretty generic, and am welcome to suggestions. Get/set *field* imply that this applies only to structs, but it also works with arrays. I would

FYI, I wrote up some thoughts on this here: http://nondot.org/sabre/LLVMNotes/MemoryUseMarkers.txt The intention is to allow front-ends to express things like "I know this memory is a constant in this region" and to allow the optimizer/ codegen to perform more aggressive stack slot merging. -Chris

On Feb 23, 2011, at 2:47 AM, David Given wrote: > On 02/23/11 02:46, Chris Lattner wrote: > [...] >> Remember that this isn't intended to be something users deal with, it's just an internal implementation detail of the compiler, debugger, nm implementation, etc. > > Can I put in a plea to have as much of LLVM as possible *not* require > knowledge of a single,

On 2008-04-27, at 15:56, Chris Lattner wrote: > On Apr 27, 2008, at 12:49 PM, Nick Lewycky wrote: > >> Chris Lattner wrote: >> >>> On Apr 27, 2008, at 10:58 AM, Talin wrote: >>> >>>> I would certainly make use of this in my frontend. >>>> >>>> I suggest the names "getfield" and "setfield" for the two

On Feb 23, 2011, at 3:24 PM, Stephen Wilson wrote: >> >> On the other hand, if "Byte Order" makes sense to include, should >> other parts of targetdata be included? Pointer size seems the next >> most desirable -- endianness and pointer size would be sufficient for >> many elf tools, for example. However, the other parts of >> targetdata could

On Apr 27, 2008, at 12:49 PM, Nick Lewycky wrote: > Chris Lattner wrote: >> On Apr 27, 2008, at 10:58 AM, Talin wrote: >> >>> I would certainly make use of this in my frontend. >>> >>> I suggest the names "getfield" and "setfield" for the two >>> operations, >>> >> >> I agree that

...hu, 25 Aug 2005, Nicola Lugato wrote: > Another question: > What's the best way in general to implement interfaces (like java ones > for example)? Any hint ? I'm just in the dark with this. Along with what the others said, you might find these notes useful: http://nondot.org/sabre/LLVMNotes/MSILObjectModel1.txt http://nondot.org/sabre/LLVMNotes/MSILObjectModel2.txt Which includes interfaces. Alkis may have notes for llvm-java as well. -Chris -- http://nondot.org/sabre/ http://llvm.org/

...rote: > Hi Sohail, > >> Is LLVM expressive enough to represent asynchronous exceptions? > > not currently. The first step in this direction is to get rid of the invoke > instruction and attach exception handling information to basic blocks. See > http://nondot.org/sabre/LLVMNotes/ExceptionHandlingChanges.txt > for a discussion. Is this really a good idea? Why have a control flow graph if it doesn't actually capture control flow? There are lots of compilers for languages with more pervasive exceptions that represent them explicitly, e.g. the Hotspot server compiler...