similar to: [LLVMdev] structs get decomposed when shouldn't

Hi David, > I'm new on the list, so I want to say hello for everybody! hello! > I'm from Hungary and writing a LLVM backend for Tile64 processor as my > master's thesis. It's a big time pressure on me, so the thesis will > probably describe a backend only providing an assembly printer, but the > development is likely to be continued beyond the thesis. > >

On Wednesday 02 May 2012 09:12:16 Duncan Sands wrote: > > As I can understand, LLVM is trying to decompose datatypes into smaller > > components in some circumstances. > > Can you please explain more what you are referring to here. LLVM itself > shouldn't be changing function parameters or return types unless the > function has local (internal) linkage (since in that

Hi Tim, On 02/05/12 10:51, Tim Northover wrote: > On Wednesday 02 May 2012 09:12:16 Duncan Sands wrote: >>> As I can understand, LLVM is trying to decompose datatypes into smaller >>> components in some circumstances. >> >> Can you please explain more what you are referring to here. LLVM itself >> shouldn't be changing function parameters or return

Hi Duncan, On Wednesday 02 May 2012 10:15:17 Duncan Sands wrote: > yup, front-ends have to take care of more complicated ABI details. For > example the front-end should currently use "byval" for any (parts of) > structs that need to be passed on the stack, and explicit scalars for > struct bits that should go in registers. > > If this interface could be improved, I

Dear R People: In the function "decompose", the object has the class of "decomposed.ts". (from package stats) I would like to see the class definition and the method for the plotting. However, when I use isClass("decomposed.ts") I get "FALSE". When I check getMethods("plot") there is no method for plot on decomposed.ts Any suggestions,

As many of you will know, handling of struct arguments in LLVM is actually slightly more fiddly than you might expect. For targets where aggregates are always passed on the stack it's easy enough, the Clang ABI code marks these arguments as byval and the call lowering code in LLVM will copy the object to the stack when needed. There are more options for when the target has more complex ABI

Hi, I would like to inform the community that I'm releasing the backend for tile64 I developed in the past several months. It can be downloaded from http://pnyf.inf.elte.hu/juhda/projects/tilera/ The version for LLVM 3.1 is a minimalist functioning implementation. Now I am working on utilizing the VLIW packetizer of LLVM, and other improvements are planned for the future. I would be

The decompose() function truncates the seasonal component unnecessarily. I've modified the function to fix this problem, and also added the original data to the object returned (to enable better plotting). I've also modified the plot.decomposed.ts() function so that it plots the original data in the top panel rather than the reconstructed data. The difference between the two is that the

On Wed, Sep 05, 2012 at 07:48:48PM +0200, JUHASZ David wrote: > Hi, > > I would like to inform the community that I'm releasing the backend for > tile64 I developed in the past several months. It can be downloaded from > > http://pnyf.inf.elte.hu/juhda/projects/tilera/ > > The version for LLVM 3.1 is a minimalist functioning implementation. Now > I am working on

Hi, In the past months, several options have been presented for making byval (and similar attributes, such as inalloca or sret) work with opaque pointers. The main two I've seen were byval(T) and byval(N) where N is the size of T. They both have their upsides and downsides, for example: byval(T) would be a type-parametric attribute, which, AFAIK, does not already exist and may complicate

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

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

On Tue, Jul 8, 2008 at 2:28 AM, Matthijs Kooijman <matthijs at stdin.nl> wrote: > Hi all, > > I've been discussing parameter attributes and their impact on first-class > struct parameters. Duncan and I came to the conclusion that the only attribute > that could be applied to structs currently, is the inreg attribute. However, > since there is no support anywhere for

Hi all, I've been discussing parameter attributes and their impact on first-class struct parameters. Duncan and I came to the conclusion that the only attribute that could be applied to structs currently, is the inreg attribute. However, since there is no support anywhere for that currently (transformation passes and backends?), it might be better to disallow the inreg attribute for struct

> Do all tests need it? Align is just for non-default alignment (> align(1)) so it may be OK for the tests to omit it & it's probably not right to /require/ an align attribute on a byval parameter. I've had to fix some of the tests which checked that the right alignment was applied, by looking at the generated asm, but had no "align A" attributes and relied on the

On Mon, Mar 16, 2015 at 9:56 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > so just using pointer types instead of i64 will help common cases, but > will not address the general issue. Now part of this does some down to > using array parameters as a substitute for byval/direct parameters. As I > recall, this was done because it allowed a natural partial decomposition >

Hi Dan, > The requirement to update all callers' call instructions when a callee > gets a new return value is also present in the current MRV-mechanism > with getresult. It's not been a problem we've worried about so far. I didn't mean you can get away without updating your calllers, I'm just saying it could be a bit easier. > Can you give some background about

Hello, In my LLVM frontend (CLR/MSIL), I am currently using first-class aggregates to represent loaded value types on the "CLR stack". However, I noticed that when calling external method taking those aggregate by value, they were not passed as I expected: %COLORREF = type { i8, i8, i8, i8 } declare i32 @SetLayeredWindowAttributes(i8*, %COLORREF, i8, i32) I call this function with

Hello, I'm trying to change the default behavior for how structures are passed to functions to use pass-by-value. Currently LLVM's default behavior is to pass structures by reference. I'm not disputing the benefits of this but I really want to change the default behavior for experimentation purposes. To this end I've changed the code in DefaultABIInfo::classifyArgumentType() to

On Jun 2, 2008, at 11:11 PM, Tanya Lattner wrote: > Darwin/ppc: > SingleSource/Benchmarks/CoyoteBench/fftbench [ CBE ] > From what I can see comparing 2.3 with TOT, the "cexp" function is declared like this in 2.3: declare i128 @cexp({double, double}* byval) nounwind It used to be this: declare void @cexp({double, double}* noalias sret, {double, double}* byval)