search for: llvmnote

Displaying 20 results from an estimated 297 matches for "llvmnote".

Did you mean: llvmnotes
2008 Apr 27
8
[LLVMdev] Two new 'llvmnotes'
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
2008 May 05
0
[LLVMdev] Two new 'llvmnotes'
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 {{{...
2008 Apr 27
0
[LLVMdev] Two new 'llvmnotes'
...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 > ______...
2008 May 05
0
[LLVMdev] Two new 'llvmnotes'
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...
2008 May 05
1
[LLVMdev] Two new 'llvmnotes'
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...
2011 Feb 23
0
[LLVMdev] New TargetSpec 'llvmnote'
...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...
2011 Feb 23
0
[LLVMdev] New TargetSpec 'llvmnote'
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
2011 Feb 23
0
[LLVMdev] New TargetSpec 'llvmnote'
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
2008 Apr 27
0
[LLVMdev] Two new 'llvmnotes'
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
2008 May 07
0
[LLVMdev] Two new 'llvmnotes'
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
2008 May 07
2
[LLVMdev] Two new 'llvmnotes'
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
2008 May 07
0
[LLVMdev] Two new 'llvmnotes'
> 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
2008 Apr 27
2
[LLVMdev] Two new 'llvmnotes'
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
2009 May 18
5
[LLVMdev] memory lifetime and invariance
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
2011 Feb 23
2
[LLVMdev] New TargetSpec 'llvmnote'
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,
2008 Apr 27
0
[LLVMdev] Two new 'llvmnotes'
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
2011 Feb 24
0
[LLVMdev] New TargetSpec 'llvmnote'
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
2008 Apr 27
3
[LLVMdev] Two new 'llvmnotes'
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
2005 Aug 27
0
[LLVMdev] Mapping of class derivated and interfaces
...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/
2011 Jun 12
6
[LLVMdev] Is LLVM expressive enough to represent asynchronous exceptions?
...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...