On Tue, Sep 15, 2009 at 11:55 AM, Dan Gohman <gohman at apple.com> wrote:> > On Sep 15, 2009, at 8:32 AM, Kenneth Uildriks wrote: > >> In the latest snapshot from SVN on X86, llc refuses to compile >> functions returning structs larger than two i32 members. >> >> According to the docs, such limitations can be expected to exist on >> other platforms. >> >> This leads to a number of questions and observations: >> >> 1. Is there a good way to retrieve the current target limitations on >> struct return sizes? > > No. The information can be inferred from what's in the *CallingConv.td > files, though there are currently no utilities specifically for this. > >> 2. The sretpromotion pass does not take struct size limitations into >> account; it will happily convert an sret parameter with five members >> into a return value that llc chokes on. >> >> 3. There is no sretdemotion pass. >> >> 4. If the answer to #1 is "no", perhaps we need platform-specific >> sretpromotion and sretdemotion passes to allow small struct returns to >> happen efficiently while large struct returns can be successfully >> codegen'd, all without having to build such platform-specific >> knowledge into all front-ends. > > Sure. Alternatively, we could fix codegen to do this itself. I'd be > happy to help anyone interested in working on this. > > I recently made a major reorganization of the calling-convention > lowering code which cleared away one of the major obstacles to > doing this within codegen. > > DanThat would be even better. I suppose codegen would have to do something like the sret parameter demotion when the number of members exceeds the number of available registers? Or did you have something else in mind? Fixing this would make my front-end noticeably simpler, and would probably benefit other front-ends as well, so I'd be willing to spend some time on it.
Kenneth Uildriks wrote:> On Tue, Sep 15, 2009 at 11:55 AM, Dan Gohman <gohman at apple.com> wrote: > >> On Sep 15, 2009, at 8:32 AM, Kenneth Uildriks wrote: >> >> >>> In the latest snapshot from SVN on X86, llc refuses to compile >>> functions returning structs larger than two i32 members. >>> >>> According to the docs, such limitations can be expected to exist on >>> other platforms. >>> >>> This leads to a number of questions and observations: >>> >>> 1. Is there a good way to retrieve the current target limitations on >>> struct return sizes? >>> >> No. The information can be inferred from what's in the *CallingConv.td >> files, though there are currently no utilities specifically for this. >> >> >>> 2. The sretpromotion pass does not take struct size limitations into >>> account; it will happily convert an sret parameter with five members >>> into a return value that llc chokes on. >>> >>> 3. There is no sretdemotion pass. >>> >>> 4. If the answer to #1 is "no", perhaps we need platform-specific >>> sretpromotion and sretdemotion passes to allow small struct returns to >>> happen efficiently while large struct returns can be successfully >>> codegen'd, all without having to build such platform-specific >>> knowledge into all front-ends. >>> >> Sure. Alternatively, we could fix codegen to do this itself. I'd be >> happy to help anyone interested in working on this. >> >> I recently made a major reorganization of the calling-convention >> lowering code which cleared away one of the major obstacles to >> doing this within codegen. >> >> Dan >> > > That would be even better. I suppose codegen would have to do > something like the sret parameter demotion when the number of members > exceeds the number of available registers? Or did you have something > else in mind? > > Fixing this would make my front-end noticeably simpler, and would > probably benefit other front-ends as well, so I'd be willing to spend > some time on it. > >It would definitely help my front end :) -- Talin
On Wednesday 16 September 2009 07:03:55 Talin wrote:> Kenneth Uildriks wrote: > > That would be even better. I suppose codegen would have to do > > something like the sret parameter demotion when the number of members > > exceeds the number of available registers? Or did you have something > > else in mind? > > > > Fixing this would make my front-end noticeably simpler, and would > > probably benefit other front-ends as well, so I'd be willing to spend > > some time on it. > > It would definitely help my front end :)And mine! -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e