search for: mergedglob

...> that makes use of that information could affect the profitability of > > the GlobalMerge pass? > > It could, and does, from what I've seen (beware anecdata): > - reusing the adrp base prevents optimizing it (the various > Adrp*{ldr,str} LOHs). > - reusing the adrp+add MergedGlobal pointer, with indexed addressing, > doesn't prevent the AdrpAdd optimization. > > All in all, whether GlobalMerge is profitable or not (by increasing > register pressure, or adding another indirection), whenever the LOH > optimizations fire, they reduce its usefulness. > &gt...

...that information could affect the profitability of >> > the GlobalMerge pass? >> >> It could, and does, from what I've seen (beware anecdata): >> - reusing the adrp base prevents optimizing it (the various >> Adrp*{ldr,str} LOHs). >> - reusing the adrp+add MergedGlobal pointer, with indexed addressing, >> doesn't prevent the AdrpAdd optimization. >> >> All in all, whether GlobalMerge is profitable or not (by increasing >> register pressure, or adding another indirection), whenever the LOH >> optimizations fire, they reduce its...

...pass information and a linker > that makes use of that information could affect the profitability of > the GlobalMerge pass? It could, and does, from what I've seen (beware anecdata): - reusing the adrp base prevents optimizing it (the various Adrp*{ldr,str} LOHs). - reusing the adrp+add MergedGlobal pointer, with indexed addressing, doesn't prevent the AdrpAdd optimization. All in all, whether GlobalMerge is profitable or not (by increasing register pressure, or adding another indirection), whenever the LOH optimizations fire, they reduce its usefulness. AFAICT, the only case where LOH...

Hi Ahmed, Did you run these experiments on a platform with a linker that makes use of the AArch64CollectLOH-pass-produced information? I'm guessing that the AArch64CollectLOH-pass information and a linker that makes use of that information could affect the profitability of the GlobalMerge pass? Thanks, Kristof > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu

...For > > example, take test/CodeGen/ARM/global-merge-addrspace.ll > > > > ; RUN: llc < %s -mtriple=thumb-apple-darwin -O3 | FileCheck %s > > ; Test the GlobalMerge pass. Check that the pass does not crash when using > > ; multiple address spaces. > > ; CHECK: _MergedGlobals: > > @g1 = internal addrspace(1) global i32 1 > > @g2 = internal addrspace(1) global i32 2 > > ; CHECK: _MergedGlobals1: > > @g3 = internal addrspace(2) global i32 3 > > @g4 = internal addrspace(2) global i32 4 > > > > With my change, the symbol is named...

...the profitability of > >> > the GlobalMerge pass? > >> > >> It could, and does, from what I've seen (beware anecdata): > >> - reusing the adrp base prevents optimizing it (the various > >> Adrp*{ldr,str} LOHs). > >> - reusing the adrp+add MergedGlobal pointer, with indexed addressing, > >> doesn't prevent the AdrpAdd optimization. > >> > >> All in all, whether GlobalMerge is profitable or not (by increasing > >> register pressure, or adding another indirection), whenever the LOH > >> optimizatio...

...ll always be correct, but the tests as written do not pass. For example, take test/CodeGen/ARM/global-merge-addrspace.ll ; RUN: llc < %s -mtriple=thumb-apple-darwin -O3 | FileCheck %s ; Test the GlobalMerge pass. Check that the pass does not crash when using ; multiple address spaces. ; CHECK: _MergedGlobals: @g1 = internal addrspace(1) global i32 1 @g2 = internal addrspace(1) global i32 2 ; CHECK: _MergedGlobals1: @g3 = internal addrspace(2) global i32 3 @g4 = internal addrspace(2) global i32 4 With my change, the symbol is named MergedGlobals.1, hence it fails this test. I could change these 60...