similar to: [LLVMdev] CPP API User-level Question: Returning multiple values

Dan, Thanks for the info. Unfortunately for the time being we are using (for the most part) the 2.3 release (with a couple of patches that Dave Greene has applied). The first-class aggregates is one of the things we don't yet have in the LLVM we're working with. I'll look again to see if there's a ReturnInst::Create( ) which I can pass an array of llvm::Value *'s to,

On Sep 12, 2008, at 9:40 AM, Tony Scudiero wrote: > Greetings, Hi Tony, This is an area that's undergone some changes recently. The LLVM 2.3 multiple-return-value (MRV) syntax has been replaced by the first-class aggregates syntax in SVN trunk. > > I'm working on getting our compiler's interface to LLVM to mimic > the > way the LLVM-GCC inserts instructions to

Hi Tony, I just checked LLVM 2.3 and ReturnInst has these: static ReturnInst* Create(Value * const* retVals, unsigned N, Instruction *InsertBefore) static ReturnInst* Create(Value * const* retVals, unsigned N, BasicBlock *InsertAtEnd) which are what you're looking for. In LLVM trunk, MRV-syntax LLVM assembly files and bitcode

On Jun 9, 2008, at 4:14 AM, Duncan Sands wrote: > Hi, > >> Will sretpromotion still be needed? If the frontends would generate >> functions >> returning a struct directly instead of using an sret argument, sret >> could >> perhaps be removed alltogether? Though I guess there is an ABI >> difference >> between using sret and returning a

Hi Dan, > Yes, the intention is that getresult will be removed once first-class > aggregates are a ready replacement. This won't leave LLVM missing the > concept of returning multiple values; a struct can be thought of as > a container for multiple values. I'm not saying we don't have some way of modeling multiple return values, I'm sayin the explicit concept

It appears the syntax for returning multiple values has changed since 2.9. Previous to that: ret i32 %a, i32 %b worked. The new syntax is something like: ret { i32, i32 }{i32 %a, i32 %b} but this yields an error: mrv-bug.ll:5:24: error: invalid use of function-local name ret { i32, i32 }{i32 %a, i32 %b} ^ If %a and %b are replaced by constants, things work. Am I

On Jun 2, 2008, at 8:45 AM, Matthijs Kooijman wrote: > Hi Dan, > >> Yes, the intention is that getresult will be removed once first-class >> aggregates are a ready replacement. This won't leave LLVM missing the >> concept of returning multiple values; a struct can be thought of as >> a container for multiple values. > I'm not saying we don't have some

Hi, I'm gonna try to give some feedback, but I have only been working with LLVM for a few days, so don't take what I'm saying without verifying :-) > BasicBlock *ProgSlicer::CloneBasicBlock(const BasicBlock *BB, > DenseMap<const Value*, Value*> &ValueMap, > const char *NameSuffix, Function *F) { > > BasicBlock

Hi all, I am trying to write a pass where i am creating a clone of a function (the only difference being, the new function returns void , instead of any value). I am creating a new Function Type with a void return type (rest being the same as original function), and using this i am creating a new function body. Then, i clone the body of the old function into new function, but when ever i

On 10/10/13 10:43 AM, Hongxu Chen wrote: > Hi, this question might be a bit silly: apart from the language > reference(http://llvm.org/docs/LangRef.html#switch-instruction) page, are > there additional rules for a regular llvm frontend to generate llvm IRs? > > There are a few cases that I got from clang/llvm-gcc/dragonegg when > compiling *C* source code into llvm IR: > >

On Fri, Oct 11, 2013 at 12:06 AM, John Criswell <criswell at illinois.edu>wrote: > On 10/10/13 10:43 AM, Hongxu Chen wrote: > >> Hi, this question might be a bit silly: apart from the language >> reference(http://llvm.org/**docs/LangRef.html#switch-**instruction<http://llvm.org/docs/LangRef.html#switch-instruction>) >> page, are >> there additional rules

Hi, this question might be a bit silly: apart from the language reference(http://llvm.org/docs/LangRef.html#switch-instruction) page, are there additional rules for a regular llvm frontend to generate llvm IRs? There are a few cases that I got from clang/llvm-gcc/dragonegg when compiling *C* source code into llvm IR: 1. It seems that there is ONLY ONE ReturnInst(and NO InvokeInst) for such llvm

Hi Chris, On Sat, Jun 07, 2008 at 02:59:03PM -0700, Chris Lattner wrote: > On Jun 2, 2008, at 1:03 PM, Matthijs Kooijman wrote: > >> Can you give some background about what kinds of things you're > >> thinking > >> about for this? > > For example, when I have a function returning {i32, i32} and I want > > to add > > another i32 to that. If

Hi, I'm really interested in this effort. What is its status? Is any of it in svn yet? (I only see the insert/extract value instructions so far... nothing w.r.t. creating a first-class struct/array). Can I do anything to help? Marc On Mon, Jun 9, 2008 at 9:15 AM, Devang Patel <dpatel at apple.com> wrote: > > On Jun 9, 2008, at 4:14 AM, Duncan Sands wrote: > >> Hi,

Function's have three kinds of optional data: prefix data, prologue data, and personalities. We don't have a consistent way of storing this data, IMO. This RFC discusses a new way of managing optional data that makes llvm::Function cleaner, more consistent, and a little smaller. What do we do currently? ======================== Prefix and prologue data are attached to Functions via

On 5/17/2011 11:37 PM, Duncan Sands wrote: > Hi George, > >> Does llvm provide a way to determine instructions that cause control to >> leave functions? For example, return statements and exit statements cause >> control exit out of function. > there is no "exit" statement. > > I am looking for something similar to basic block >> terminators.

Hi all, I've been implementing some stuff that uses the new structs-as-firstclass values code. Apart from some implementation problems, I'm spotting a few structural problems that seem non-trivial to fix. In particular, now that structs are a first class values, the old way or returning multiple values is a bit confusing. The old way had a variable number of arguments to the return

I work with David Greene and I've been looking into the x86-64 ABI. Right now I'm working with the 2.3 release of LLVM and LLVM-GCC 4.2/2.3 (binary release for linux). I'm unable to replicate the results you posted here - I'm getting wildly different output. I wonder what I'm doing wrong. I suspect it has something to do with my not being able to pass it the -m64 or --64

Quoting hc2428 at columbia.edu: Dear staff, Here is the bc file. Heming > Quoting Chris Lattner <clattner at apple.com>: > > Dear staff, > I am using the ds-aa to pass mysqld. I compile mysqld 4.0.12 > statically (compile all libraries statically to the executable) and > got the bc file, named it as mysqld.bc3. > I use the command to pass: > > opt

On May 30, 2008, at 9:11 AM, Matthijs Kooijman wrote: > Hi all, > > I've been implementing some stuff that uses the new structs-as- > firstclass > values code. Apart from some implementation problems, I'm spotting a > few > structural problems that seem non-trivial to fix. Hi, thanks for your interest! > Furthermore, as far as I've understood, the