similar to: [LLVMdev] multiple return value assembler regression?

On Jun 24, 2011, at 9:29 AM, Bagel wrote: > 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} >

On 06/24/2011 03:45 PM, Chris Lattner wrote: > > On Jun 24, 2011, at 9:29 AM, Bagel wrote: > >> 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:

On Jun 24, 2011, at 2:21 PM, Bagel wrote: >> This is obsolete and deprecated syntax that is dropped in "llvm 3.0" (and thus on mainline right now). If you run that through llvm-as|llvm-dis from llvm 2.9, you'll see the preferred syntax. >> >> -Chris > > OK, I guess I missed the announcement that it was obsolete. It will eventually be in the llvm 3.0

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,

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 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

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

Please add to the ProjectsWithLLVM/ page. Thanks. ==== Embedded System Language (ESL) ESL <code.google.com/p/esl/> is a new programming language designed to be used for efficient programming of embedded systems and other low-level system programming projects. ESL is a typed compiled language with features that allow the programmer to dictate the concrete representation of data values;

Greetings, I'm working on getting our compiler's interface to LLVM to mimic the way the LLVM-GCC inserts instructions to generate AMD64 ABI compliant code. I'm trying to create ret i64 %mrv, double %double_mrv37 which is basically what LLVM-GCC puts out. However if I use lcc -march=cpp to get the API code I need it has the following line:

On 06/24/2011 05:21 PM, Chris Lattner wrote: > > On Jun 24, 2011, at 2:21 PM, Bagel wrote: > >>> This is obsolete and deprecated syntax that is dropped in "llvm 3.0" >>> (and thus on mainline right now). If you run that through >>> llvm-as|llvm-dis from llvm 2.9, you'll see the preferred syntax. >>> >>> -Chris >> >>

On 02/16/2017 12:08 PM, Stephen Canon wrote: >> On Feb 16, 2017, at 9:12 AM, Bagel <bagel99 at gmail.com >> <mailto:bagel99 at gmail.com>> wrote: >> >> I figured that the optimization of this would bedifficult (else it would >> have already been done :-)) > > Don’t make this assumption. There’s lots of opportunities for optimization > scattered

> On Feb 21, 2017, at 9:54 PM, Nemanja Ivanovic via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I believe that providing additional intrinsics that would directly produce the ISD::ADDC/ISD::SUBC nodes would provide the additional advantage of being able to directly produce these nodes for code that doesn't have anything to do with multiprecision addition/subtraction. I am

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,

Would someone be so kind as to tell me what the status of debugging symbols (DWARF) generated by clang/llvm is? I am on a linux x86-64 system (Fedora 13). Is gdb supposed to understand the generated DWARF? When I generate an executable with "clang -g" followed by "llc -O0" and feed it to gdb, I get "no debugging symbols found". What is the status of lldb on

It takes two "llvm.uadd.with.overflow" instances to model the add-with-carry when there is a carry-in. Look at the IR generated by the example. I figured that the optimization of this would bedifficult (else it would have already been done :-)). And would this optimization have to be done for every architecture? On 02/15/2017 04:28 PM, Stephen Canon wrote: > > Why do you think

On 23 November 2010 18:03, Bagel <bagel99 at gmail.com> wrote: > Would someone be so kind as to tell me what the status of debugging symbols > (DWARF) generated by clang/llvm is? Hi Bagel, It should be fairly complete... > When I generate an executable with "clang -g" followed by "llc -O0" and feed it > to gdb, I get "no debugging symbols found".

On 12/03/2010 06:28 PM, Devang Patel wrote: > We are working on a document. Here is current draft: > http://wiki.llvm.org/Debug_Information > > - > Devang While this is great news, it doesn't completely satisfy my needs. Your documentation assumes one is going to use the LLVM provided functions (such as DIFactory::). My front-end can't use them because it is not

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

I am writing a backend for an experimental machine that has both 2-address and 3-address versions of some instructions. The 2-address versions are more compact and thus preferred when applicable. How does one go about generating the most compact version? 1. At instruction selection, is there a predicate that can test whether one of the input sources is dead, thus allowing the selection of the

On 09/11/2014 05:33 PM, Quentin Colombet wrote: > Hi Brian, > > On Sep 11, 2014, at 3:03 PM, Bagel <bagel99 at gmail.com> wrote: > >> When the IR specifies a 32 bit load can it be changed to a narrower >> load? What if the load is from memory (e.g. a peripheral) that only >> supports 32-bit access? Consider the following IR: ---- target datalayout >> =