similar to: Use of array type in globals in LTO

On 2016-08-26 12:47, Mehdi Amini wrote: >> On Aug 26, 2016, at 9:06 AM, junbuml at codeaurora.org wrote: >> >> On 2016-08-26 11:32, Mehdi Amini wrote: >>> Hi, >>>> Recently, I noticed that less number of global variables are merged >>>> in global-merge pass and in some global variable, array types are >>>> used instead of its

On 2016-08-26 11:32, Mehdi Amini wrote: > Hi, > >> Recently, I noticed that less number of global variables are merged in >> global-merge pass and in some global variable, array types are used >> instead of its original type. For example, [4xi8] with align 4 is used >> for a i32 global variable. For me, it seems that such pattern is >> observed after

Thanks for the test case! I can reproduce this, and see with the compiler I saved from just before r278338 that this is indeed a chance in behavior. Looking at why this changed... On Fri, Aug 26, 2016 at 1:42 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> On Aug 26, 2016, at 1:34 PM, junbuml at codeaurora.org wrote: >> >> On 2016-08-26 12:47, Mehdi Amini wrote:

> On Aug 26, 2016, at 2:06 PM, Teresa Johnson <tejohnson at google.com> wrote: > > Mehdi: I see what is going on: > > + ArrayType *Ty = > + ArrayType::get(Type::getInt8Ty(RegularLTO.Ctx), I.second.Size); > + GlobalVariable *OldGV = RegularLTO.CombinedModule->getNamedGlobal(I.first); > + if (OldGV && OldGV->getType()->getElementType()

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

On Thu, Feb 26, 2015 at 2:33 AM, Kristof Beyls <kristof.beyls at arm.com> wrote: > > Hi Ahmed, > > Did you run these experiments on a platform with a linker that makes > use of the AArch64CollectLOH-pass-produced information? As Jim says, I'm on iOS, so yes. However, I'm mostly running tests with the pass disabled. > > I'm guessing that the

Hi all, I've started looking at the GlobalMerge pass, enabled by default on ARM and AArch64. I think we should reconsider that, at least for AArch64. As is, the pass just merges all globals together, in groups of 4KB (AArch64, 128B on ARM). At the time it was enabled, the general thinking was "it's almost free, it doesn't affect performance much, we might as well use it".

On Thu, Feb 26, 2015 at 4:09 AM, Renato Golin <renato.golin at linaro.org> wrote: > On 26 February 2015 at 00:57, Ahmed Bougacha <ahmed.bougacha at gmail.com> wrote: >> -- A way forward >> One obvious way to improve it is: look at uses of globals, and try to >> form sets of globals commonly used together. The tricky part is to >> define heuristics for

On 26 February 2015 at 00:57, Ahmed Bougacha <ahmed.bougacha at gmail.com> wrote: > -- A way forward > One obvious way to improve it is: look at uses of globals, and try to > form sets of globals commonly used together. The tricky part is to > define heuristics for "commonly". Also, the pass then becomes much > more expensive. I'm currently looking into

On Fri, Feb 27, 2015 at 1:38 PM Ahmed Bougacha <ahmed.bougacha at gmail.com> wrote: > On Thu, Feb 26, 2015 at 2:33 AM, Kristof Beyls <kristof.beyls at arm.com> > wrote: > > > > Hi Ahmed, > > > > Did you run these experiments on a platform with a linker that makes > > use of the AArch64CollectLOH-pass-produced information? > > As Jim says,

On Fri, Feb 27, 2015 at 1:42 PM, Eric Christopher <echristo at gmail.com> wrote: > > > On Fri, Feb 27, 2015 at 1:38 PM Ahmed Bougacha <ahmed.bougacha at gmail.com> > wrote: >> >> On Thu, Feb 26, 2015 at 2:33 AM, Kristof Beyls <kristof.beyls at arm.com> >> wrote: >> > >> > Hi Ahmed, >> > >> > Did you run these

Hi, When I’m compiling a code with –fvisibility=hidden –fPIC for ARM, I find that LLVM generates less optimized code than GCC. For example: test.cpp: void init(void *); int g0[100]; int g1[100]; int g2[100]; void foo() { init(&g0); init(&g1); init(&g2); } Clang will emit 1 GOT entry for each GV and 2 instructions to get the address: ldr

>> Any thoughs? > > I'm now struggling to see how GCC justifies it. What if a different > translation-unit declared those variables in a different order? I also > can't get the same behaviour here, do you have a more complete > command-line? Ah, I see; the translation-unit that does the optimisation needs to have them as a definition (i.e. "= {0}") rather

Hi, I'm trying to turn on a flag (-inline-generic-switch-cost) introduced in r301649 which improved the inline cost heuristic for switch. In my experiment for LLVM test suite and spec2000/2006 in AArch64, +17.82% performance and -8% code size reduce was observed in spec2000/vertex with O3 LTO. No significant code size / performance regression was found in O3/O2/Os. Before we turn this

> On Feb 27, 2015, at 2:03 PM, Ahmed Bougacha <ahmed.bougacha at gmail.com> wrote: > > On Thu, Feb 26, 2015 at 4:09 AM, Renato Golin <renato.golin at linaro.org> wrote: >> On 26 February 2015 at 00:57, Ahmed Bougacha <ahmed.bougacha at gmail.com> wrote: >>> -- A way forward >>> One obvious way to improve it is: look at uses of globals, and try to

Hi Ahmed, Yes. I'd share with Kristof and Renato's concerns, and the impact/dependence upon link-time tool should be clarified before disabling this pass. On the other hand, actually the test on our hardware shows disabling this pass without LTO considered, some spec benchmarks would have big regressions, (positive is bad) spec.cpu2000.ref.253_perlbmk 3.27% spec.cpu2000.ref.254_gap

Hi Eric, all, Currently, there isn't a good way to force enable/disable GlobalMerge. Targets decide whether to create the pass based on the optimization level (which is how it should be). The problem is when you want to override that decision. We have -enable-global-merge, true by default, which should really be -disable-global-merge, as it only works as a last-resort way to force-disable

On Fri, Feb 27, 2015 at 2:13 PM Ahmed Bougacha <ahmed.bougacha at gmail.com> wrote: > On Fri, Feb 27, 2015 at 1:42 PM, Eric Christopher <echristo at gmail.com> > wrote: > > > > > > On Fri, Feb 27, 2015 at 1:38 PM Ahmed Bougacha <ahmed.bougacha at gmail.com > > > > wrote: > >> > >> On Thu, Feb 26, 2015 at 2:33 AM, Kristof Beyls

Can you share you compile-time and memory footprint measurements at least for CTMark? For a new pass/feature it would be great to share this with the community before you commit. Or did I miss them? Thanks Gerolf > On Jun 27, 2017, at 3:26 PM, Geoff Berry via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > EarlyCSE w/ MemorySSA has been enabled by default as of r306477 >

Hi, I am trying to create a pass that is similar to the GlobalMerge code found here: http://llvm.org/docs/doxygen/html/GlobalMerge_8cpp_source.html I am concerned with lines 149-163 of the above file. From the documentation at the top of the file, it will convert this: static int foo[N], bar[N], baz[N]; for (i = 0; i < N; ++i) { foo[i] = bar[i] * baz[i]; } Into something like this