search for: sretpromotion

...runk) - r127723 [PR6270] PathV1::makeUnique() - r127731, r127732, r127733, r127734, r127775 [PR9234] test/CodeGen/X86 tweaks. - r127872 [PR6745] format("%e") Even with these patches, a few tests may fail. It seems {VS8 | VS10} Release are good. - VS8 Debug LLVM :: Transforms/SRETPromotion/basictest.ll LLVM-Unit :: support/debug/SupportTests.exe/CastingTest.cast - VS9 Debug LLVM :: Transforms/SRETPromotion/basictest.ll LLVM-Unit :: Support/Debug/SupportTests.exe/CastingTest.cast - VS9 Release LLVM :: CodeGen/ARM/bfi.ll LLVM :: CodeGen/ARM/va_arg.ll LLVM...

Hi, The attached patch removes sretpromotion from docs/Passes.html The sretpromotion pass got removed in version 3.0 Cheers, Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: Passes.html.patch Type: text/x-patch Size: 1904 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/at...

...le 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? 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...

...ber 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 &g...

...ghts. I think that simply using insertvalue for now and not having an explicit multiple return function attribute should work fine. Whenever I want to add a function argument, I will just let it return a struct of two elements (current value and the new value). I'll also add a feature to the sretpromotion pass that flattens out nested struct return types as much as possible, without having to reconstruct structs at the caller end (ie, preserver struct types that are used in any way other than extractvalue in any caller and flatten out all other elements). Would this be the right place for that? Or s...

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

...ase, I'm glad to have someone with a different perspective thinking about this feature :-). > > > Whenever I want to add a function argument, I will just let it > return a struct > of two elements (current value and the new value). > > I'll also add a feature to the sretpromotion pass that flattens out > nested > struct return types as much as possible, without having to > reconstruct structs > at the caller end (ie, preserver struct types that are used in any > way other > than extractvalue in any caller and flatten out all other elements). > W...

They are good. I am checking with Release now. 20> Clang :: CodeGenObjC/image-info.m I will investigate it later. ...Takumi vs8 20>Failing Tests (3): 20> Clang :: CodeGenObjC/image-info.m 20> LLVM :: Transforms/SRETPromotion/basictest.ll 20> LLVM-Unit :: support/debug/SupportTests.exe/CastingTest.cast 20> Expected Passes : 8106 20> Expected Failures : 73 20> Unsupported Tests : 552 20> Unexpected Failures: 3 vs9 10>Failing Tests (2): 10> LLVM :: Transforms/SRETPromotion/basictest.ll...

...n internal functions, though, so it does not have to deal with ABI issues. If you want to support the C ABI (which requires a pointer in the first argument to return any struct AFAIK), you might be better off generating such code in your frontend. Any internal function can then be simplified by the sretpromotion pass (perhaps it could be modified to take an option for the maximum number of elements to put in the real return struct?) Not sure how to go about this exactly, but perhaps this helps a bit. Gr. Matthijs -------------- next part -------------- A non-text attachment was scrubbed... Name: signatu...

...regardless of what it returned before [with the exception of void functions, of course...]). This approach could possibly result in ugly nested structs like {{{{i32},i32},i32},i32} after adding three values, for example. Considering that adding return values is really not used anywhere except for sretpromotion (and there not really either), this is probably not a big deal. However, for our particular applications we like the function results to be as flat as possible, to simplify our codegeneration. > Ok. And as I mentioned before, we can add buildagg (maybe with a > different name ;-)) Yeah, bui...

Chris Lattner wrote: > On Jul 20, 2008, at 10:59 AM, Richard Pennington wrote: > I'm sure the implementation will take the same approach, but it won't > necessarily be ABI compatible. I don't know enough to say at this > point... it may end up being ABI compatible or not depending on > implementation details. Hi Chris, I was thinking about my problem and thought

...lder, but I might move some code into there. > stretpromotion was really just for testing. I expect that when MRVs > work predictably 100% of the time (even if not something the ABI > supports, for example) that the functionality will be pulled into the > argpromotion pass. 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? Gr. Matthijs -------------- next pa...

...ieve 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 &quo...

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

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

On May 30, 2008, at 9:11 AM, Matthijs Kooijman wrote: > Hi all, > > I've been implementing some stuff that uses the new structs-as- > firstclass > values code. Apart from some implementation problems, I'm spotting a > few > structural problems that seem non-trivial to fix. Hi, thanks for your interest! > Furthermore, as far as I've understood, the

...e though our backend to read > insertvalue chains, > so it won't be really necessary anymore :-) But let's keep it in mind. If you're using IRBuilder, why not just add a new CreateBuildMRV method that inserts the sequence of insertvalue's for you? > Reconsidering, the sretpromotion pass might not be the best place > for this. It > currently promotes the special sret pointer arguments to multiple > return > values (I should probably modify it to use a struct return and > insertvalue > instead?). Since an sret function will, by definition, have a void...

Hi all, I've been implementing some stuff that uses the new structs-as-firstclass values code. Apart from some implementation problems, I'm spotting a few structural problems that seem non-trivial to fix. In particular, now that structs are a first class values, the old way or returning multiple values is a bit confusing. The old way had a variable number of arguments to the return

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

..., though, so it does not have > to deal with ABI issues. If you want to support the C ABI (which requires a > pointer in the first argument to return any struct AFAIK), you might be > better off generating such code in your frontend. Any internal function can > then be simplified by the sretpromotion pass (perhaps it could be modified > to take an option for the maximum number of elements to put in the real > return struct?) This is not the same on all architectures. For x86-64, for example, structs are returned through the hidden first argument except if they are small enough, in which...