search for: ldrs

I have two questions regarding MachineMemOperands and dependence information. Q1) I noticed that MachineMemOperands are lost when two LDRs are combined and a LDRD is generated in ARMPreAllocLoadStoreOpt:::RescheduleOps. (before optimization) %reg1033<def> = LDR %reg1030, %reg0, 4100, pred:14, pred:%reg0; mem:LD4[%uglygep10] %reg1054<def> = LDR %reg1030, %reg0, 4104, pred:14, pred:%reg0; mem:LD4[%uglygep2021] (after optim...

On Sep 7, 2010, at 10:48 AM, Akira Hatanaka wrote: > I have two questions regarding MachineMemOperands and dependence information. > > Q1) I noticed that MachineMemOperands are lost when two LDRs are combined and a LDRD is generated in ARMPreAllocLoadStoreOpt:::RescheduleOps. > > (before optimization) > %reg1033<def> = LDR %reg1030, %reg0, 4100, pred:14, pred:%reg0; mem:LD4[%uglygep10] > %reg1054<def> = LDR %reg1030, %reg0, 4104, pred:14, pred:%reg0; mem:LD4[%uglyge...

...2010 at 1:31 PM, Bill Wendling <wendling at apple.com> wrote: > On Sep 7, 2010, at 10:48 AM, Akira Hatanaka wrote: > > > I have two questions regarding MachineMemOperands and dependence > information. > > > > Q1) I noticed that MachineMemOperands are lost when two LDRs are combined > and a LDRD is generated in ARMPreAllocLoadStoreOpt:::RescheduleOps. > > > > (before optimization) > > %reg1033<def> = LDR %reg1030, %reg0, 4100, pred:14, pred:%reg0; > mem:LD4[%uglygep10] > > %reg1054<def> = LDR %reg1030, %reg0, 4104, pred:14...

...t;>>>> determines a final addressing expression as a simple form (e.g., >>>>>>> ptrtoint/add/inttoptr) and sinks it into user's block so that >>>>>>> ISel >>>>>>> could have better chance to fold address computation into LDRs >>>>>>> and >>>>>>> STRs. However, OptimizeMemoryInst() seems to do this >>>>>>> transformation even when the address calculation derived from a >>>>>>> single GEP, resulting in poor alias analysis because GEP is no...

...other operations are used for the address calculation, OptimizeMemoryInst() performs address matching and determines a final addressing expression as a simple form (e.g., ptrtoint/add/inttoptr) and sinks it into user's block so that ISel could have better chance to fold address computation into LDRs and STRs. However, OptimizeMemoryInst() seems to do this transformation even when the address calculation derived from a single GEP, resulting in poor alias analysis because GEP is no longer used. So, do you think it is a possible workaround to sink a GEP without converting it into a set of intege...

...g and >>>>>> determines a final addressing expression as a simple form (e.g., >>>>>> ptrtoint/add/inttoptr) and sinks it into user's block so that >>>>>> ISel >>>>>> could have better chance to fold address computation into LDRs >>>>>> and >>>>>> STRs. However, OptimizeMemoryInst() seems to do this >>>>>> transformation even when the address calculation derived from a >>>>>> single GEP, resulting in poor alias analysis because GEP is no >>>&gt...

...NumDups2=1_, which makes sense because BB#8 and BB#9 share the same _LDRrs_ instruction with the same operands. The problem is the call to _TTI->removeBranch(...)_ function that does not remove the _BX_ instruction. Thus, when removing the common instructions, the _BX_ is removed instead of the _LDRs_ instruction. > # Before removeBranch call on MBB1 > BB#9: derived from LLVM BB %if.else.i.i.i.i > Live Ins: %LR %R0 %R1 %R2 %R4 %R5 %R6 %R7 %R8 %R9 %R10 %R12 > Predecessors according to CFG: BB#7 > STRBi12 %R6, %R7<kill>, 0, pred:14, pred:%noreg; mem:ST1[%21](align=4) > %...

...s > > calculation, OptimizeMemoryInst() performs address matching and > > determines a final addressing expression as a simple form (e.g., > > ptrtoint/add/inttoptr) and sinks it into user's block so that ISel > > could have better chance to fold address computation into LDRs and > > STRs. However, OptimizeMemoryInst() seems to do this > > transformation even when the address calculation derived from a > > single GEP, resulting in poor alias analysis because GEP is no > > longer used. > > I don't follow your last statement. How does th...

...other operations are used for the address calculation, OptimizeMemoryInst() performs address matching and determines a final addressing expression as a simple form (e.g., ptrtoint/add/inttoptr) and sinks it into user's block so that ISel could have better chance to fold address computation into LDRs and STRs. However, OptimizeMemoryInst() seems to do this transformation even when the address calculation derived from a single GEP, resulting in poor alias analysis because GEP is no longer used. I don't follow your last statement. How does this impact AA? CodeGenPrep is run late, after AA is...

...t() performs address matching and > >>> determines a final addressing expression as a simple form (e.g., > >>> ptrtoint/add/inttoptr) and sinks it into user's block so that > >>> ISel > >>> could have better chance to fold address computation into LDRs > >>> and > >>> STRs. However, OptimizeMemoryInst() seems to do this > >>> transformation even when the address calculation derived from a > >>> single GEP, resulting in poor alias analysis because GEP is no > >>> longer used. > >&gt...

...t; calculation, OptimizeMemoryInst() performs address matching and >>> determines a final addressing expression as a simple form (e.g., >>> ptrtoint/add/inttoptr) and sinks it into user's block so that ISel >>> could have better chance to fold address computation into LDRs and >>> STRs. However, OptimizeMemoryInst() seems to do this >>> transformation even when the address calculation derived from a >>> single GEP, resulting in poor alias analysis because GEP is no >>> longer used. >> >> I don't follow your last st...

...address matching and >>>>> determines a final addressing expression as a simple form (e.g., >>>>> ptrtoint/add/inttoptr) and sinks it into user's block so that >>>>> ISel >>>>> could have better chance to fold address computation into LDRs >>>>> and >>>>> STRs. However, OptimizeMemoryInst() seems to do this >>>>> transformation even when the address calculation derived from a >>>>> single GEP, resulting in poor alias analysis because GEP is no >>>>> longer use...

...) psr : 0000101008222018 ifs : 8000000000000a98 ip : >[<f0000000040375a0>] >(XEN) ip is at csched_schedule+0x970/0xf70 >(XEN) unat: 0000000000000000 pfs : 0000000000000a98 rsc : 0000000000000003 >(XEN) rnat: 0000121008226018 bsps: f00000000405a6c0 pr : 000000000001aaa9 >(XEN) ldrs: 0000000000000000 ccv : 0000000000000000 fpsr: 0009804c8a70033f >(XEN) csd : 0000000000000000 ssd : 0000000000000000 >(XEN) b0 : f0000000040375a0 b6 : f000000004049c80 b7 : e000000000100800 >(XEN) f6 : 0fffbccccccccc8c00000 f7 : 0ffd9a200000000000000 >(XEN) f8 : 0ffff8000000000000...

Hi Alex: I was looking at an ia64 bug report and noticed that we don''t actually free IRQs in the free_irq_vector hypercall. This would eventually lead to alloc_irq_vector failing. Unless I''m mistaken something like calling pci_disable_device and pci_enable_device can lead to this situation. So I''m wondering what the original problem was and how could we resolve it

...akes sense because BB#8 > and BB#9 share the same *LDRrs* instruction with the same operands. The > problem is the call to *TTI->removeBranch(...)* function that does not > remove the *BX* instruction. Thus, when removing the common instructions, > the *BX* is removed instead of the *LDRs* instruction. > > # Before removeBranch call on MBB1 > BB#9: derived from LLVM BB %if.else.i.i.i.i > Live Ins: %LR %R0 %R1 %R2 %R4 %R5 %R6 %R7 %R8 %R9 %R10 %R12 > Predecessors according to CFG: BB#7 > STRBi12 %R6, %R7<kill>, 0, pred:14, pred:%noreg; mem:ST1[%21](ali...

...ch psr : 0000101008422010 ifs : 8000000000000307 ip : [<a0000001004c2ca0>] Not tainted (2.6.26-rc4xen-ia64-dirty) ip is at dev_kfree_skb_irq+0x20/0x1a0 unat: 0000000000000000 pfs : 400000000000040b rsc : 0000000000000007 rnat: 0000000000000000 bsps: 0000000000000000 pr : 000000000000a941 ldrs: 0000000000000000 ccv : 0000000000000000 fpsr: 0009804c8a70433f csd : 0000000000000000 ssd : 0000000000000000 b0 : a0000001003efb70 b6 : a000000100070e40 b7 : a000000100070e40 f6 : 1003e000000fcb75352b1 f7 : 1003e000000000014ff97 f8 : 1003e00fcb74fc3454d80 f9 : 1003e0000000080000000 f10 : 10...

...ch psr : 0000101008422010 ifs : 8000000000000307 ip : [<a0000001004c2ca0>] Not tainted (2.6.26-rc4xen-ia64-dirty) ip is at dev_kfree_skb_irq+0x20/0x1a0 unat: 0000000000000000 pfs : 400000000000040b rsc : 0000000000000007 rnat: 0000000000000000 bsps: 0000000000000000 pr : 000000000000a941 ldrs: 0000000000000000 ccv : 0000000000000000 fpsr: 0009804c8a70433f csd : 0000000000000000 ssd : 0000000000000000 b0 : a0000001003efb70 b6 : a000000100070e40 b7 : a000000100070e40 f6 : 1003e000000fcb75352b1 f7 : 1003e000000000014ff97 f8 : 1003e00fcb74fc3454d80 f9 : 1003e0000000080000000 f10 : 10...

...ch psr : 0000101008422010 ifs : 8000000000000307 ip : [<a0000001004c2ca0>] Not tainted (2.6.26-rc4xen-ia64-dirty) ip is at dev_kfree_skb_irq+0x20/0x1a0 unat: 0000000000000000 pfs : 400000000000040b rsc : 0000000000000007 rnat: 0000000000000000 bsps: 0000000000000000 pr : 000000000000a941 ldrs: 0000000000000000 ccv : 0000000000000000 fpsr: 0009804c8a70433f csd : 0000000000000000 ssd : 0000000000000000 b0 : a0000001003efb70 b6 : a000000100070e40 b7 : a000000100070e40 f6 : 1003e000000fcb75352b1 f7 : 1003e000000000014ff97 f8 : 1003e00fcb74fc3454d80 f9 : 1003e0000000080000000 f10 : 10...

On Nov 12, 2013, at 11:24 AM, Junbum Lim <junbums at gmail.com> wrote: > > I wonder why CodeGenPrepare breaks GEP into integer calculations (ptrtoin/add/inttopt) instead of directly sinking the address calculation using GEP into user's block. I believe it's primary for address mode matching where only part of the GEP can be folded (depending on the instruction set). Evan

I wonder why CodeGenPrepare breaks GEP into integer calculations (ptrtoin/add/inttopt) instead of directly sinking the address calculation using GEP into user's block. Thanks, Jun On Nov 12, 2013, at 12:07 PM, Evan Cheng <evan.cheng at apple.com> wrote: > The reason for this is to allow folding of address computation into loads and stores. A lot of modern arch, e.g. X86 and arm,