search for: builddag

...Is that the dependence I want? I don't know how to read these graphs. Is the code that's supposed to do this in ScheduleDAGBuild.cpp? Thanks for your help. -Dave -------------- next part -------------- A non-text attachment was scrubbed... Name: reset.builddag.ps Type: application/postscript Size: 40025 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090903/d233c1c3/attachment.ps>

On Thu, Sep 3, 2009 at 5:55 PM, David Greene<dag at cray.com> wrote: > On Thursday 03 September 2009 18:22, David Greene wrote: > >> > Since scheduling and selection is mostly within a block, hopefully it >> > wouldn't be too hard to come up with a testcase? >> >> Yep, I've got a much reduced testcase now (and converted from Fortran >> to C

...ertvalue you can do something like: %a = phi { i32, i32 } [ %a.0, %foo ], [ %a.1, %bar ] %b = insertvalue { i32, i32 } %a, i32 0, 0 which you can't do directly using a literal { } or buildagg kind of instruction. OTOH, you can still do things like this using nested structs then, so having a builddag will probably not improve things much. Anyhow, so much for my blabbering of incoherent thoughts. 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 st...

...> %a = phi { i32, i32 } [ %a.0, %foo ], [ %a.1, %bar ] > %b = insertvalue { i32, i32 } %a, i32 0, 0 > > which you can't do directly using a literal { } or buildagg kind of > instruction. OTOH, you can still do things like this using nested > structs > then, so having a builddag will probably not improve things much. > > Anyhow, so much for my blabbering of incoherent thoughts. I think > that simply > using insertvalue for now and not having an explicit multiple return > function > attribute should work fine. Ok. And as I mentioned before, we can add...

...ion (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, builddag is an ugly name :-p > later if we find it would be of significant use or convenience. By then, we will probably have though our backend to read insertvalue chains, so it won't be really necessary anymore :-) But let's keep it in mind. > In any case, I'm glad to have someone with...

...tingVoid.txt This would make it so that calls always return a value, and 'ret' always takes a value. This would be a nice simplification to the IR I think. > > > >> Ok. And as I mentioned before, we can add buildagg (maybe with a >> different name ;-)) > Yeah, builddag is an ugly name :-p > >> later if we find it would be of significant use or convenience. > By then, we will probably have 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 IRBuil...

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

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