search for: _multiple

...| > | > | > | // assign 'a' to R3, and load M1 into R3 > c := a c(Ry) := a(R3) > > So, the register is necessary for doing the reloading. Yes. But as you show above, it may happen that the same spilled virtual interval is reloaded into _multiple different_ physical registers during its lifetime. So, what is the reason to assign only one (!) physical register to the virtual interval by means of VRM.assignVirt2Phys() and to do it actually in advance? What is the semantics of it? I'd really like to understand it better. How does this solv...

...ias for a 1.0 release of Wine? I couldn't find one. I was looking in the developers mailing list. But there's only a collection of bugs that must be fixed. An important question for me is: How many native DLLs will be accepted for a 1.0 version? I don't get the point that installing _multiple _native libraries to make an application installable and/or runnable solves a bug report, but on the other side the goal is to be free of native DLLs if possible. Other possible criterias: * All downloadable software must run (a very practical criteria). * Software with Linux ports is...

Hi, Roman, maybe I can try to answer this. I think that all boils down to having register to reload spilled values. Once a register is spilled, its live range is split into smaller pieces. These pieces most be contained into registers, and it is the task of the allocator to find these registers. Imagine that you have something like: Before After allocation: allocation: a

Hi Evan, I have a few questions about current implementation of live intervals spilling, which is required for the implementation of Extended Linear Scan algorithm. --- Evan Cheng <evan.cheng at apple.com> wrote: > > On Wednesday 23 January 2008 02:01, Evan Cheng wrote: > >> On Jan 22, 2008, at 12:23 PM, David Greene wrote: > >>> Evan, > >>> >

Hi All, I've more or less finished updating the examples to the DAG style we were talking about. Hopefully I haven't forgotten anything, there was a lot to keep track of :-). Overall, I think there's a couple places where things get a a little awkward (mainly debug info) but things generally look good to me. A Simple Example def : GICombineRule<(defs reg:$D, reg:$S),

...te extreme. I think it should be possible to find an algorithm that makes an intelligent decision for defs with multiple uses. > As you can see, this discussion also makes me wonder whether the (defs) are needed at all; maybe we can rely on type inference almost everywhere? > > >> _Multiple roots_ >> This one requires algorithm changes which I'd prefer not to discuss in this RFC. Assuming the underlying algorithm gains support for this, this is how the syntax would look: >> def : GICombineRule< >> (defs root:$root1, root:$root2, reg:$A, reg:$B), >> (...

Hi All, I've been working on the GlobalISel combiner recently and I'd like to share the plan for how Combine Rules will be defined in GlobalISel and solicit feedback on it. This email ended up rather long so: TL;DR: We're planning to define GlobalISel Combine Rules using MIR syntax with a few bits glued on to interface with the algorithm and escape into C++ when we need to.

...))>; > Thanks again for your detailed reply! > Cheers, > Nicolai > > > >>> As you can see, this discussion also makes me wonder whether the (defs) are needed at all; maybe we can rely on type inference almost everywhere? >>> >>> >>>> _Multiple roots_ >>>> This one requires algorithm changes which I'd prefer not to discuss in this RFC. Assuming the underlying algorithm gains support for this, this is how the syntax would look: >>>> def : GICombineRule< >>>> (defs root:$root1, root:$root2, reg:$...