search for: vpvalu

...'d like the review to proceed separately from this bigger (and most likely longer) discussion. We intentionally made the interfaces similar such that whatever the outcome of this discussion would be, the changes we have to make later, if any, is small and mechanical. We just need to agree that VPValue/VPUser/VPInstruction is not a precedence, i.e., still subject to ongoing discussion and is expected to abide by the eventual outcome of this discussion. To the best of my understanding, if we do not want to modify the IR (i.e., CFG, Instructions, and Uses/Defs hooked up in the Function) before we...

...s and algorithms that already exist and have matured. I agree. So, I dream about a lighter weight version of Value class hierarchy where many of the standard Value class hierarchy algorithm can run, without making lighter weight stuff hooked into the actual IR state. We intentionally tried to make VPValue/VPUser/VPInstruction interfaces "subset of" Value/User/Instruction interfaces such that the code sharing (not copying/pasting) can be possible. This is practical enough so far, but I'm still wondering, in a long run, whether we can do something better. Thus, constructive ideas are we...

...~2yrs ago, it's unlikely that you'll get overwhelming support on "copy the entire function" before the decision to transform is taken. So, if this part is optional, you may want to state that. Having said that, in https://reviews.llvm.org/D38676, we are introducing concepts like VPValue, VPUser, and VPInstruction, in order to manipulate and interact with things that didn't come from the IR of the original loop (nest). As such, I can see why you think "a playground copy of IR" is beneficial. Even before reading your RFC, I was actually thinking that someone else may...

...l get overwhelming > support on "copy the entire function" before the decision > > to transform is taken. So, if this part is optional, you may want to > state that. > > > > Having said that, in https://reviews.llvm.org/D38676, we are > introducing concepts like VPValue, VPUser, and VPInstruction, > > in order to manipulate and interact with things that didn't come from > the IR of the original loop (nest). As such, I can see > > why you think "a playground copy of IR" is beneficial. Even before > reading your RFC, I was actually t...

On 10/14/2017 05:28 PM, Daniel Berlin via llvm-dev wrote: > > > On Sat, Oct 14, 2017 at 2:54 PM, Michael Kruse <llvmdev at meinersbur.de > <mailto:llvmdev at meinersbur.de>> wrote: > > 2017-10-14 5:03 GMT+02:00 Daniel Berlin <dberlin at dberlin.org > <mailto:dberlin at dberlin.org>>: > > FWIW: We hit a subset of this issue with