similar to: [LLVMdev] Structs as first class values.

On Jul 20, 2008, at 6:25 AM, Richard Pennington wrote: > Hi, > > I'm trying to implement structs as first class values. If I assemble > > It assembles without complaint. Yep, the code looks fine. > If I do llc I get an assert: > > > My questions are: > > Is this supposed to work? (I understand it may be a work in > progress.) Yes, that is supposed to

Chris Lattner wrote: > On Jul 20, 2008, at 6:25 AM, Richard Pennington wrote: > Yes, that is supposed to work in theory. In practice, most targets > only support returning up to two values in registers. Eventually, we > want the code generator to support returning excess return values on > the stack, but we don't have that code yet. Thanks for the info. Is the intention

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 structure directly? right, there's an ABI difference. Also you can't return variable sized structs using

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

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

On Jul 20, 2008, at 10:59 AM, Richard Pennington wrote: > Chris Lattner wrote: >> On Jul 20, 2008, at 6:25 AM, Richard Pennington wrote: >> Yes, that is supposed to work in theory. In practice, most targets >> only support returning up to two values in registers. Eventually, we >> want the code generator to support returning excess return values on >> the stack,

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,

Eli Friedman wrote: > 2009/8/2 Richard Pennington <rich at pennware.com>: >> The following fails on x86_64 because of the output constraint '0'. >> My question is, is this legal. LLVM complains about the size difference >> (32 vs 64), but it is the same register (ax). >> Works on x86. >> >> %42 = call i64 asm sideeffect

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

----- Original Message ----- > From: "Hal Finkel via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Richard Pennington" <rich at pennware.com> > Cc: llvm-dev at lists.llvm.org > Sent: Wednesday, September 7, 2016 7:37:50 AM > Subject: Re: [llvm-dev] [PowerPC] Recent branch too far breakage > > Hi Rich, > > It is hard to tell, but there

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

2009/8/2 Richard Pennington <rich at pennware.com>: > Eli Friedman wrote: >> 2009/8/2 Richard Pennington <rich at pennware.com>: >>> The following fails on x86_64 because of the output constraint '0'. >>> My question is, is this legal. LLVM complains about the size difference >>> (32 vs 64), but it is the same register (ax). >>>

A while back (2012) there were a few messages related to using YAML config files to set up how clang would build stuff, especially for cross compilers. My ELLCC project is entirely cross compilation focused, so today I decided to play around with the config file idea. Right now it only handles replacing a "-target foo" option with the options defined in the file foo in the

On Sun, Aug 16, 2009 at 11:47 AM, Richard Pennington<rich at pennware.com> wrote: > Richard Pennington wrote: >> >> Hi, >> >> The enclosed patch preserves debug information about compilation units, >> functions, and line number information when doing bitcode linking. I'm not >> easily able to try this for non-bitcode linking. Could someone familiar

I'm trying to implement *MUL_LOHI for my processor. My processor has mulxss (e.g.) that gives the 32 high bits of a 64 bit multiply. I tried this in ios2ISelDAGToDAG.cpp: /// Mul/Div with two results case ISD::SMUL_LOHI: case ISD::UMUL_LOHI: { SDValue Op1 = Node->getOperand(0); SDValue Op2 = Node->getOperand(1); AddToISelQueue(Op1);

Hi, I know my last question was very vague (i.e. "It stopped working, what went wrong?"), so here is a little more concrete example: If I run the optimizer (opt) on this code snippet with -std-compile-opts the optimizer hangs. ; ModuleID = 'test.ubc' target datalayout =

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,

(Fixed the cfe email address) On 12/18/2015 09:34 PM, Tim Northover wrote: > On 18 December 2015 at 19:15, Richard Pennington via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> It turns out that it can with some simple patches. > This sounds really cool. I think we should seriously consider putting > these patches into LLVM mainline. > >> Information on

On Sat, May 17, 2008 at 11:34 AM, Richard Pennington <rich at pennware.com> wrote: > If I run the optimizer (opt) on this code snippet with -std-compile-opts > the optimizer hangs. > > > ; ModuleID = 'test.ubc' > target datalayout = >

I've just started looking into code generation and have a newbie question: Is there enough information in the .td files to make a tool to automatically generate an assembler from them? Is a project like that in the works? -Rich