similar to: [LLVMdev] Two new 'llvmnotes'

Hi Chris, > Eliminating the 'Void' Type: > http://nondot.org/sabre/LLVMNotes/EliminatingVoid.txt might not some ABI's require some special stuff when returning a struct, regardless of whether the struct is empty or not? If so this might add a cost if you use {} for void. Also, there are an infinite number of different ways of returning void: return {} or {{}} or {{{}}} etc,

I would certainly make use of this in my frontend. I suggest the names "getfield" and "setfield" for the two operations, since (to me anyway) "insert" implies adding something new, as opposed to overwriting an existing value. Chris Lattner wrote: > Hi all, > > For anyone interested, I posted two new ideas for changes to the LLVM > IR. The first is

On Apr 27, 2008, at 12:49 PM, Nick Lewycky wrote: > Chris Lattner wrote: >> On Apr 27, 2008, at 10:58 AM, Talin wrote: >> >>> I would certainly make use of this in my frontend. >>> >>> I suggest the names "getfield" and "setfield" for the two >>> operations, >>> >> >> I agree that

On Apr 27, 2008, at 10:58 AM, Talin wrote: > I would certainly make use of this in my frontend. > > I suggest the names "getfield" and "setfield" for the two operations, > I agree that 'get/insertvalue' are pretty generic, and am welcome to suggestions. Get/set *field* imply that this applies only to structs, but it also works with arrays. I would

On 2008-04-27, at 15:56, Chris Lattner wrote: > On Apr 27, 2008, at 12:49 PM, Nick Lewycky wrote: > >> Chris Lattner wrote: >> >>> On Apr 27, 2008, at 10:58 AM, Talin wrote: >>> >>>> I would certainly make use of this in my frontend. >>>> >>>> I suggest the names "getfield" and "setfield" for the two

Chris Lattner wrote: > On Apr 27, 2008, at 10:58 AM, Talin wrote: > >> I would certainly make use of this in my frontend. >> >> I suggest the names "getfield" and "setfield" for the two operations, >> > > I agree that 'get/insertvalue' are pretty generic, and am welcome to > suggestions. Get/set *field* imply that this applies

Chris Lattner wrote: > Aggregates as First Class Values: > http://nondot.org/sabre/LLVMNotes/FirstClassAggregates.txt > Thinking more about this...I kinda wish it was available right *now*, because I sure could use it. I've been working on functions returning structures today, and in the current IR I basically have two choices: Either return the struct using multiple return

Hi Talin, On May 5, 2008, at 1:13 AM, Talin wrote: > Chris Lattner wrote: >> Aggregates as First Class Values: >> http://nondot.org/sabre/LLVMNotes/FirstClassAggregates.txt >> > Thinking more about this...I kinda wish it was available right *now*, > because I sure could use it. I've been working on functions returning > structures today, and in the current IR I

On Wed, 7 May 2008, Matthijs Kooijman wrote: >> Aggregates as First Class Values: > it seems to me that having this would make the byval parameter attribute > partly obsolete? Will there be semantic differences between passing a struct > directly and a pointer to a struct byval? > > I can see that byval can be used on pointers to other things, but is that > really useful? I

Hi, > Aggregates as First Class Values: it seems to me that having this would make the byval parameter attribute partly obsolete? Will there be semantic differences between passing a struct directly and a pointer to a struct byval? I can see that byval can be used on pointers to other things, but is that really useful? I can't see any use for compiling C code, are there other languages

> Byval and passing a first class aggregate have the same semantics. > However, byval is very efficient for large aggregates and first-class > aggregates is efficient for small ones. I was making the assumption that having the same semantics actually means being equivalent and thus resulting in the same generated code. Since, AFAICS, the LLVM IR mainly conveys semantics, what do both

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

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

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 this was a function that simply returns two > i32 > values, any caller will only use extractvalue on

TL;DR: Have support in ADT for typed values packing into opaque scalar types - Code & design choices: https://reviews.llvm.org/D81580 - Usage: https://reviews.llvm.org/differential/changeset/?ref=2005337&whitespace=ignore-most - Example of rewrite: https://reviews.llvm.org/D81662 *CONTEXT* There are places in LLVM where we need to pack typed fields into opaque values. For instance,

Hi Guillaume, Thanks for the RFC. I'm generally +1 on the concept. Making bit field manipulation easier seems like a good overall goal given its prevalence in LLVM. As for the syntax, I tend to prefer that we don't pollute the namespace. Have you considered pushing the methods into the Bitfield class? Maybe something like: ``` uint8_t Storage = 0; using Amount =

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

Hi Tim, Thought about it last night and was coming to the same conclusion. 1. it cant be done at the end during lowering (target backend). 2. it should be part of llvm as the byVal needs to be handled. As a twist, I have been told that llvm-gcc can lower byVal into memcpy in the callee. I may take a look at this. I wonder if it ever emits 'byVal'... I still feel I don't understand

In particular, I would for example like to prevent that two fields of type i32 are packed into an i64 parameter. And so on... Thanks! -- Zvonimir

Reid is right that this would go in memcpyopt, but... we there's an active discussion on the commit list which will solve this through a different mechanism. There's an active desire to avoid teaching GVN and related pieces (of which memcpyopt is one) about first class aggregates. We don't have enough active users of the feature to justify and maintain the complexity. If you