similar to: [LLVMdev] Indirect goto

On 2010-01-03 10:33, Chris Lattner wrote: > If you're interested in this new extension, here is some more information with some less-than-obvious aspects of the design: > http://blog.llvm.org/2010/01/address-of-label-and-indirect-branches.html > > This feature was added to LLVM by Bob Wilson, Dan Gohman and I to mainline back in November. If you have questions or comments about

2010/1/3 Török Edwin <edwintorok at gmail.com>: > On 2010-01-03 10:33, Chris Lattner wrote: >> If you're interested in this new extension, here is some more information with some less-than-obvious aspects of the design: >> http://blog.llvm.org/2010/01/address-of-label-and-indirect-branches.html >> >> This feature was added to LLVM by Bob Wilson, Dan Gohman and

Hello, I have a question about the indirectbr instruction. I attempted to use it according to the example in the Assembly Language Reference manual, but got an "expected instruction opcode" error. Poking about on the web I found this document: http://nondot.org/sabre/LLVMNotes/IndirectGoto.txt which appears to be a Nov 2, 2009 proposal to add indirectbr and blockaddress() to the IR

On Jan 2, 2010, at 11:03 AM, Dustin Laurence wrote: > Hello, > > I have a question about the indirectbr instruction. I attempted to > use > it according to the example in the Assembly Language Reference manual, > but got an "expected instruction opcode" error. Poking about on the > web > I found this document: > >

Hello, I have a question about the indirectbr instruction. I attempted to use it according to the example in the Assembly Language Reference manual, but got an "expected instruction opcode" error. Poking about on the web I found this document: http://nondot.org/sabre/LLVMNotes/IndirectGoto.txt which appears to be a Nov 2, 2009 proposal to add indirectbr and blockaddress() to the IR

So, that means that &&(Label) operator, which is defined in C++, is also not supported currently in LLVM. I thought I could obtain address of basic block indirectly through this small hack but it does not seem to work. Actually, I tried to make folloing dummy C++ code which uses this operator: *int main(int argc,char** argv) { int x; int y; L1:

I would certainly make use of this in my frontend. I suggest the names "getfield" and "setfield" for the two operations, since (to me anyway) "insert" implies adding something new, as opposed to overwriting 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

If you're interested in this new extension, here is some more information with some less-than-obvious aspects of the design: http://blog.llvm.org/2010/01/address-of-label-and-indirect-branches.html This feature was added to LLVM by Bob Wilson, Dan Gohman and I to mainline back in November. If you have questions or comments about the post, this is a good thread to discuss them on :) -Chris

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

On Sep 11, 2009, at 9:57 AM, Chris Lattner wrote: > Devang's work on debug info prompted this, thoughts welcome: > http://nondot.org/sabre/LLVMNotes/ExtensibleMetadata.txt The document mentions "instructions" a lot. We'll want to be able to apply metadata to ConstantExprs as well at least, if not also Arguments (think noalias) and other stuff, so it seems best to just

On Sep 11, 2009, at 2:11 PM, Dan Gohman wrote: > > On Sep 11, 2009, at 9:57 AM, Chris Lattner wrote: > > >> Devang's work on debug info prompted this, thoughts welcome: >> http://nondot.org/sabre/LLVMNotes/ExtensibleMetadata.txt > > The document mentions "instructions" a lot. We'll want to be able to > apply metadata to ConstantExprs as well at

On Thu, 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

On Sep 11, 2009, at 7:17 PM, Nick Lewycky wrote: > Dan Gohman wrote: >> On Sep 11, 2009, at 9:57 AM, Chris Lattner wrote: >>> Devang's work on debug info prompted this, thoughts welcome: >>> http://nondot.org/sabre/LLVMNotes/ExtensibleMetadata.txt >> The document mentions "instructions" a lot. We'll want to be able to >> apply metadata to

Chris Lattner wrote: > > On Sep 11, 2009, at 7:17 PM, Nick Lewycky wrote: > >> Dan Gohman wrote: >>> On Sep 11, 2009, at 9:57 AM, Chris Lattner wrote: >>>> Devang's work on debug info prompted this, thoughts welcome: >>>> http://nondot.org/sabre/LLVMNotes/ExtensibleMetadata.txt >>> The document mentions "instructions" a lot.

On Thu, Nov 12, 2009 at 5:58 PM, Chris Lattner <clattner at apple.com> wrote: > On Nov 12, 2009, at 11:29 AM, Talin wrote: > > > Well, as far as intp goes (or iptr if you prefer - the naming convention in > LLVM is i<size>) > > > How about "intptr". > > here's what I would expect: > > - General rule #1: If an instruction accepts

On Nov 12, 2009, at 11:29 AM, Talin wrote: > > Well, as far as intp goes (or iptr if you prefer - the naming > convention in LLVM is i<size>) How about "intptr". > here's what I would expect: > General rule #1: If an instruction accepts both i32 and i64, then it > should accept iptr as well. If it only accepts i32, then it can > continue to only

Dan Gohman wrote: > On Sep 11, 2009, at 9:57 AM, Chris Lattner wrote: > > >> Devang's work on debug info prompted this, thoughts welcome: >> http://nondot.org/sabre/LLVMNotes/ExtensibleMetadata.txt > > The document mentions "instructions" a lot. We'll want to be able to > apply metadata to ConstantExprs as well at least, if not also Arguments >

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 {{{}}} etc,

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

On Jul 27, 2009, at 3:05 PM, Devang Patel wrote: > On Mon, Jul 27, 2009 at 1:13 PM, Dan Gohman<gohman at apple.com> wrote: > >> >> >> On Jul 27, 2009, at 10:10 AM, Devang Patel wrote: >> >> >> >> >> >>> In LLVM IR metadata is used to attach auxiliary information with >>> >>> various IR constructs. Currently