search for: gpr64common

Ok, thank you, I will implement it then. As far as I see this optimization should be done in AArch64LoadStoreOptimizer, is it right? From: Eli Friedman [mailto:efriedma at quicinc.com] Sent: Thursday, November 21, 2019 11:55 PM To: Kosov Pavel <kosov.pavel at huawei.com>; LLVM Dev <llvm-dev at lists.llvm.org> Subject: RE: [llvm-dev] [ARM] Peephole optimization ( instructions tst +

...t fail without this assert. Add the Verbose-PBQP-dump patch and use '-debug-only=regalloc -pbqp-dump-graphs' to see the more verbose output which shows the progress of the algorithm leading to the assert: * Applied R2(NId 18)handleDisconnectEdge(9, 2) : DeniedOpts 10 -> 9 NId 9(%vreg15, GPR64common) moved to conservatively-allocatables. handleDisconnectEdge(2, 9) : DeniedOpts 10 -> 9 NId 2(%vreg4, GPR64common) moved to conservatively-allocatables. ... Popped NId 2(%vreg4, GPR64common) , all edge costs added: 2.002748e+01 inf inf inf inf inf inf inf inf inf inf ** selection: 0 llc: ../inc...

Hi Jiangning, On Apr 14, 2014, at 10:31 PM, Jiangning Liu <liujiangning1 at gmail.com> wrote: > Hi Jim, > > 2014-04-15 4:28 GMT+08:00 Jim Grosbach <grosbach at apple.com>: > This sounds reasonable. Thanks, all. > > > - CSE of ADRP optimization (Jiangning) > > Quentin may have some input here. He’s done quite a lot of optimizations for ADRP sequences.

...bose-PBQP-dump patch and use > '-debug-only=regalloc -pbqp-dump-graphs' to see the more verbose output > which shows the progress of the algorithm leading to the assert: > > > > * Applied R2(NId 18)handleDisconnectEdge(9, 2) : DeniedOpts 10 -> 9 > > NId 9(%vreg15, GPR64common) moved to conservatively-allocatables. > > handleDisconnectEdge(2, 9) : DeniedOpts 10 -> 9 > > NId 2(%vreg4, GPR64common) moved to conservatively-allocatables. > > ... > > Popped NId 2(%vreg4, GPR64common) , all edge costs added: > > 2.002748e+01 inf inf inf inf i...

> A node should never be put into the conservatively allocatable list if there is a chance of it spilling. I can understand why the logic of NodeMetadata::isConservativelyAllocatable is necessary for the node to be allocatable, but I have not been able to convince myself this is sufficient, especially when the node degree > available registers. Cheers, Arnaud From:

...ga:@_MergedGlobals_x>[TF=11] > %vreg5<def> = ADDxxi_lsl0_s %vreg4, <ga:@_MergedGlobals_x>[TF=11]; GPR64noxzr:%vreg5,%vreg4 > LS32_STR %vreg2, %vreg5<kill>, 1 > > ARM64: > > %vreg2<def> = ADRP <ga:@_MergedGlobals_x>[TF=1]; GPR64common:%vreg2 > STRWui %vreg0, %vreg2<kill>, <ga:@_MergedGlobals_x>[TF=18] > %vreg3<def> = MOVaddr <ga:@_MergedGlobals_x>[TF=1], <ga:@_MergedGlobals_x>[TF=18]; GPR64common:%vreg3 > STRWui %vreg1, %vreg3<kill>, 1 > > The problem is...

...84B %419:gpr32 = COPY %417:gpr32 7392B %414:gpr32 = COPY %412:gpr32 7400B %409:gpr32 = COPY %407:gpr32 7408B %404:gpr32 = COPY %402:gpr32 7416B %399:gpr64 = COPY %397:gpr64 7424B %394:gpr32 = COPY %392:gpr32 7528B %253:gpr32 = MOVi32imm 28 7536B STRWui %253:gpr32, %182:gpr64common, 2 :: (store 4 into %ir.106, align 8) 7752B %392:gpr32 = COPY %394:gpr32 7756B %397:gpr64 = COPY %399:gpr64 7764B %402:gpr32 = COPY %404:gpr32 7768B %407:gpr32 = COPY %409:gpr32 7776B %412:gpr32 = COPY %414:gpr32 7780B %417:gpr32 = COPY %419:gpr32 7788B %422:gpr32 = COPY...

...84B %419:gpr32 = COPY %417:gpr32 7392B %414:gpr32 = COPY %412:gpr32 7400B %409:gpr32 = COPY %407:gpr32 7408B %404:gpr32 = COPY %402:gpr32 7416B %399:gpr64 = COPY %397:gpr64 7424B %394:gpr32 = COPY %392:gpr32 7528B %253:gpr32 = MOVi32imm 28 7536B STRWui %253:gpr32, %182:gpr64common, 2 :: (store 4 into %ir.106, align 8) 7752B %392:gpr32 = COPY %394:gpr32 7756B %397:gpr64 = COPY %399:gpr64 7764B %402:gpr32 = COPY %404:gpr32 7768B %407:gpr32 = COPY %409:gpr32 7776B %412:gpr32 = COPY %414:gpr32 7780B %417:gpr32 = COPY %419:gpr32 7788B %422:gpr32 = COPY...