search for: d30751

...log contains -print-before-all -print-after-all and -debug output starting with the coalescer pass. The verification failure is right after the first pass of MachineCopyPropagation which runs after the greedy allocator. The copy propagation seemed to be working on vregs. This was extra confusing as D30751 seems to be currently reverted from trunk so I couldn't find references to that code. > >> At a first glance the odd thing there is that the operand of fladd_a32_a32_a32 is rewritten from vreg77 to vreg76, but the vreg77 operand of the BUNDLE is not. Maybe you can find out why that i...

...-print-after-all and -debug output starting with the >> coalescer pass. The verification failure is right after the first pass >> of MachineCopyPropagation which runs after the greedy allocator. > The copy propagation seemed to be working on vregs. This was extra > confusing as D30751 seems to be currently reverted from trunk so I > couldn't find references to that code. Sorry, I should have mentioned that as well. This verification error is the last problem keeping me from re-enabling the copy forwarding patch (I can send you my latest rebased version, but I don'...

On 9/26/2017 6:11 PM, Matthias Braun wrote: > >> On Sep 26, 2017, at 2:39 PM, Geoff Berry via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hi all, >> >> Mikael reported a machine verification failure in his out-of-tree target with the MachineCopyPropagation changes to forward registers (which is currently reverted). The verification in question is:

...ins -print-before-all -print-after-all and -debug output starting with the coalescer pass. The verification failure is right after the first pass of MachineCopyPropagation which runs after the greedy allocator. >> The copy propagation seemed to be working on vregs. This was extra confusing as D30751 seems to be currently reverted from trunk so I couldn't find references to that code. > > Sorry, I should have mentioned that as well. This verification error is the last problem keeping me from re-enabling the copy forwarding patch (I can send you my latest rebased version, but I don...

Hi All, I was looking into MachineCopyPropagationPass.ccp file in llvm, which in first look, looks likes to me doing only redundant copy elimination in same basic block. I am interested in any pass which is doing copy propogation across the basic block in a function. Let me know if any such pass exist ? Thanks, Deepali -------------- next part -------------- An HTML attachment was scrubbed...

Hi, I noticed that a while ago the isSSA flag was removed from MIR, and this property is now computed. However, the deduction only checks the virtual registers (whether they are assigned to more than once). Now I have MIR tests which live after RA, so they only contain physical registers, so the parser determines they are in SSA form. These tests now fail because some of our passes can be

...(unless the renaming is >>> done right after RA when virtual registers are still present, which >>> is what my current patch does, and is the source of complexity that >>> I'm trying to eliminate). >>> >>> [1] https://reviews.llvm.org/D30751 >>> [2] https://reviews.llvm.org/D39400 D39400 WIP: >>> [MachineOperand][MIR] Add isRenamable to MachineOperand. >>> >>> On 10/31/2017 5:49 AM, Raghavan, Venugopal via llvm-dev wrote: >>> >>> Hi Krzysztof, >>> >&g...

...) would also be needed for any pass that wants to rename registers after RA (unless the renaming is done right after RA when virtual registers are still present, which is what my current patch does, and is the source of complexity that I'm trying to eliminate). [1] https://reviews.llvm.org/D30751 [2] https://reviews.llvm.org/D39400 D39400 WIP: [MachineOperand][MIR] Add isRenamable to MachineOperand. On 10/31/2017 5:49 AM, Raghavan, Venugopal via llvm-dev wrote: > Hi Krzysztof, > > Thanks a lot for taking the time to write a detailed explanation. I > think I understand thing...

...e it) would also be needed for any pass that wants to rename registers after RA (unless the renaming is done right after RA when virtual registers are still present, which is what my current patch does, and is the source of complexity that I'm trying to eliminate). [1] https://reviews.llvm.org/D30751 [2] https://reviews.llvm.org/D39400 D39400 WIP: [MachineOperand][MIR] Add isRenamable to MachineOperand. On 10/31/2017 5:49 AM, Raghavan, Venugopal via llvm-dev wrote: > Hi Krzysztof, > > Thanks a lot for taking the time to write a detailed explanation. I > think I understand things...

...hat wants to rename registers after RA (unless the renaming is > done right after RA when virtual registers are still present, which > is what my current patch does, and is the source of complexity that > I'm trying to eliminate). > > [1] https://reviews.llvm.org/D30751 > [2] https://reviews.llvm.org/D39400 D39400 WIP: > [MachineOperand][MIR] Add isRenamable to MachineOperand. > > On 10/31/2017 5:49 AM, Raghavan, Venugopal via llvm-dev wrote: > > Hi Krzysztof, > > Thanks a lot for taking the time to write a de...

Hi Venu, > On Sep 11, 2017, at 11:00 PM, Raghavan, Venugopal via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Krzysztof, > > Thanks for your reply. > > I agree that adding extra register units for x86 would be the right way to fix this. Do you know if there is a plan to fix this? No concrete plan, no. We've been thinking about for quite some time now, but