search for: globalmerg

...ss? Can you >>> provide >>> an example of input IR where you see this now but didn’t before? >>> Also can you confirm you’re using the gold-linker? >> >> I used gold linker. In spec2006/perlbench, I observed the less number >> of globals are merged in GlobalMerge.cpp after r278338. The reason is >> because, from the very first pass, several global variables use [4xi8] >> with align 4, instead of its original type i32 after r278338. Current >> GlobalMerge pass doesn't seem to handle such fancy-aligned globals. If >> such type...

...more expensive. I'm currently looking into improving it, and will >> report if I come up with a good solution. But this shouldn't stop us >> from disabling it, for now. > > Hi Ahmed, > > Before "moving forward", it would be good to understand what in > GlobalMerge is impacting what in LTO. > > With LTO becoming more important nowadays, I agree we have to balance > the compiler optimisations to work well with it, but by turning things > off we might be impacting unknown code in an unknown way. > > We'll never know how unknown code behav...

...ntly looking into improving it, and will >>> report if I come up with a good solution. But this shouldn't stop us >>> from disabling it, for now. >> >> Hi Ahmed, >> >> Before "moving forward", it would be good to understand what in >> GlobalMerge is impacting what in LTO. >> >> With LTO becoming more important nowadays, I agree we have to balance >> the compiler optimisations to work well with it, but by turning things >> off we might be impacting unknown code in an unknown way. >> >> We'll never k...

...> Are you sure it is performed in the global merge pass? Can you provide > an example of input IR where you see this now but didn’t before? > Also can you confirm you’re using the gold-linker? I used gold linker. In spec2006/perlbench, I observed the less number of globals are merged in GlobalMerge.cpp after r278338. The reason is because, from the very first pass, several global variables use [4xi8] with align 4, instead of its original type i32 after r278338. Current GlobalMerge pass doesn't seem to handle such fancy-aligned globals. If such type change (e.g., from i32 to [4xi8]) i...

...l merge pass? Can you provide >>>>> an example of input IR where you see this now but didn’t before? >>>>> Also can you confirm you’re using the gold-linker? >>>> I used gold linker. In spec2006/perlbench, I observed the less number of globals are merged in GlobalMerge.cpp after r278338. The reason is because, from the very first pass, several global variables use [4xi8] with align 4, instead of its original type i32 after r278338. Current GlobalMerge pass doesn't seem to handle such fancy-aligned globals. If such type change (e.g., from i32 to [4xi8]) in gl...

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 [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Ahmed Bougacha > Sent: 26 February 2015 01:13 > To: LLVM Dev > Subject: Re: [LLVMdev] [RFC] AArch64: Should we disable GlobalMerge?...

...LOH-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 AArch64CollectLOH-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 GlobalMer...

...t; As Jim says, I'm on iOS, so yes. However, I'm mostly running tests > with the pass disabled. > > > > > 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? > > 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. &...

...on iOS, so yes. However, I'm mostly running tests >> with the pass disabled. >> >> > >> > 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? >> >> 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...

...he pass then becomes much > more expensive. I'm currently looking into improving it, and will > report if I come up with a good solution. But this shouldn't stop us > from disabling it, for now. Hi Ahmed, Before "moving forward", it would be good to understand what in GlobalMerge is impacting what in LTO. With LTO becoming more important nowadays, I agree we have to balance the compiler optimisations to work well with it, but by turning things off we might be impacting unknown code in an unknown way. We'll never know how unknown code behaves, but if at least we under...

On Fri, Feb 27, 2015 at 3:13 PM, Quentin Colombet <qcolombet at apple.com> wrote: > To be precise, GlobalMerge is registered as a pre-ISel pass, but still it runs very early in the pipeline, because all its work in done during doInitialization… Pretty broken, I know. Oh god, I forgot about this... it actually runs pretty early, not sure when exactly.. -Ahmed > -Quentin

...ovide >>>>>>> an example of input IR where you see this now but didn’t before? >>>>>>> Also can you confirm you’re using the gold-linker? >>>>>> I used gold linker. In spec2006/perlbench, I observed the less number of globals are merged in GlobalMerge.cpp after r278338. The reason is because, from the very first pass, several global variables use [4xi8] with align 4, instead of its original type i32 after r278338. Current GlobalMerge pass doesn't seem to handle such fancy-aligned globals. If such type change (e.g., from i32 to [4xi8]) in gl...

On Fri, Feb 27, 2015 at 3:48 PM Ahmed Bougacha <ahmed.bougacha at gmail.com> wrote: > On Fri, Feb 27, 2015 at 3:13 PM, Quentin Colombet <qcolombet at apple.com> > wrote: > > To be precise, GlobalMerge is registered as a pre-ISel pass, but still > it runs very early in the pipeline, because all its work in done during > doInitialization… Pretty broken, I know. > > Oh god, I forgot about this... it actually runs pretty early, not > sure when exactly.. > > During pass setup b...

...istopher <echristo at gmail.com> wrote: > > > On Fri, Feb 27, 2015 at 3:48 PM Ahmed Bougacha <ahmed.bougacha at gmail.com> > wrote: >> >> On Fri, Feb 27, 2015 at 3:13 PM, Quentin Colombet <qcolombet at apple.com> >> wrote: >> > To be precise, GlobalMerge is registered as a pre-ISel pass, but still >> > it runs very early in the pipeline, because all its work in done during >> > doInitialization… Pretty broken, I know. >> >> Oh god, I forgot about this... it actually runs pretty early, not >> sure when exactly.....

> On Feb 27, 2015, at 2:15 PM, Ahmed Bougacha <ahmed.bougacha at gmail.com> wrote: > > On Fri, Feb 27, 2015 at 2:01 PM, Renato Golin <renato.golin at linaro.org> wrote: >> On 27 February 2015 at 21:26, Ahmed Bougacha <ahmed.bougacha at gmail.com> wrote: >>> Which brings us to my fallback proposal: what about disabling the >>> pass on darwin

...9;m mostly running tests > >> with the pass disabled. > >> > >> > > >> > 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? > >> > >> 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, > &g...

...re expensive. I'm currently looking into improving it, and will > > report if I come up with a good solution. But this shouldn't stop us > > from disabling it, for now. > > Hi Ahmed, > > Before "moving forward", it would be good to understand what in > GlobalMerge is impacting what in LTO. > > With LTO becoming more important nowadays, I agree we have to balance > the compiler optimisations to work well with it, but by turning things > off we might be impacting unknown code in an unknown way. > > We'll never know how unknown code behav...

On Fri, Feb 27, 2015 at 2:01 PM, Renato Golin <renato.golin at linaro.org> wrote: > On 27 February 2015 at 21:26, Ahmed Bougacha <ahmed.bougacha at gmail.com> wrote: >> Which brings us to my fallback proposal: what about disabling the >> pass on darwin only? > > That's a decision for Jim/Evan. I'm ok if they are. Jim, thoughts? > >> As for other

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

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 f...