similar to: [LLVMdev] [ARM] [PIC] optimizing the loading of hidden global variable

Hi Rafael, Yes, merging gv prevents linker to do garbage collection. Should it be implemented as a peephole pass? If we do it too early, the distance between GVs are not fixed yet. PS: Below is the GCC output with "extern" hidden: ldr r2, .L2 stmfd sp!, {r3, lr} .save {r3, lr} .LPIC0: add r0, pc, r2 bl _Z4initPv(PLT) ldr r1, .L2+4 .LPIC1: add r0, pc, r1 bl _Z4initPv(PLT) ldr

Hi Tim, The global merge pass puts the GVs into a sturcture to guarantee their address are contiguous. It works for static GVs but for global hidden GVs, this will cause name resoltion fail during linking .o into .so Any thoughs? Thanks, Weiming > Hi Weiming, > > On 12 March 2014 17:43, Weiming Zhao <weimingz at codeaurora.org> wrote: >> Clang will emit 1 GOT entry for

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

--- On Thu, 9/20/12, Jim Grosbach <grosbach at apple.com> wrote: From: Jim Grosbach <grosbach at apple.com> Subject: Re: [LLVMdev] Proposal: New DAG node type for reciprocal operation To: "Weiming Zhao" <weimingz at codeaurora.org> Cc: llvmdev at cs.uiuc.edu Date: Thursday, September 20, 2012, 3:32 PM Sounds like a reasonable fit for a target-specific DAG combine. I

Yes, what I mean is a target independent node in the ISD::NodeType enum. I already did the node transformation DAGCombiner and target-specific lowering in the first place. It worked. But introducing a specific node will make the logic more clear. For example, in ARM, FDIV is a scalar operation. So, after DAGCombiner and Vector Type legalize, vectorized FDIV has been expanded into scalar versions,

Hi, In relaxed/fast math mode, if we can convert a/b to a * (1/b), we may get more performance when (1) "b" is loop invariant or (2) arch has faster reciprocal instruction (e.g. recipe/recips on ARM) or (3) arch has no vector div, but has vector mul and recip. So ,with this node type, a div node can be converted to a mul and a recip when desired. Then, each arch can further

Hi, For the following code: void foo (); int main () {foo();} llvm emits "bl foo" Then I set foo at a far address in linking: aarch64-linux-gnu-gcc -Wl,--defsym=foo=0x80000000 a.o -o a.exe I got an error from ld: a.c:(.text+0x8): relocation truncated to fit: R_AARCH64_CALL26 against symbol `foo' define in *ABS* section in a.exe The question is: do I

Hi Renato, It seems to me that LLVM doesn’t parse the inline asm body. It just checks the constraints, (ie. Input/output interface). During ASM writing, it then binding those constraints to placeholders like %0, %1. So it a constraint is a 64-integer type, it *probably* needs paired GPR. Weiming Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The

Sounds like a reasonable fit for a target-specific DAG combine. I suspect a target specific node wouldn't be necessary and the patterns could be matched directly. -Jim On Sep 20, 2012, at 3:26 PM, Weiming Zhao <weimingz at codeaurora.org> wrote: > Hi, > > In relaxed/fast math mode, if we can convert a/b to a * (1/b), we may get more performance when (1) “b” is loop

On Mar 13, 2013, at 10:15 AM, Weiming Zhao <weimingz at codeaurora.org> wrote: > Hi Renato, > > It seems to me that LLVM doesn’t parse the inline asm body. It just checks the constraints, (ie. Input/output interface). During ASM writing, it then binding those constraints to placeholders like %0, %1. This is correct. > So it a constraint is a 64-integer type, it *probably*

This buildbot appears to have been failing for several weeks now ( http://lab.llvm.org:8011/builders/clang-ppc64-elf-linux2/builds/19490 ). Does anyone know/own/care about it? ---------- Forwarded message ---------- From: <llvm.buildmaster at lab.llvm.org> Date: Mon, Sep 28, 2015 at 11:17 PM Subject: buildbot failure in LLVM on clang-ppc64-elf-linux2 To: Aaron Ballman <aaron at

On Tue, 2015-09-29 at 14:29 -0500, Hal Finkel wrote: > [+Bill and Bill] > > ----- Original Message ----- > > From: "David Blaikie via llvm-dev" <llvm-dev at lists.llvm.org> > > To: "llvm-dev" <llvm-dev at lists.llvm.org> > > Sent: Tuesday, September 29, 2015 12:39:02 PM > > Subject: [llvm-dev] Fwd: buildbot failure in LLVM on

r175088 attempted to fix gcc inline asm compatibility with 64-bit operands by forcing these into even/odd register pairs the same way gcc always allocates such values. While the fix appears to work as such, it is not always activated when required. The patch makes the assumption that any inline asm statement relying on the even/odd allocation will make use of the %Hn syntax to reference the high

Hi Måns, Always forcing 64-bit operands into even/odd pairs may lead to subpoptimal register allocation because not all 64 bit data requires paired regs. It seems there is no general pattern to match. Maybe we should treat it case by case. Jakob, do you have any suggestions? Thanks, Weiming Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

On 13 March 2013 13:43, Måns Rullgård <mans at mansr.com> wrote: > One possible fix, which I have tested, is to look for the specific > instructions requiring such a pair (LDRD/STRD and LDREXD/STREXD) in > addition to the 'H' modifier. However, there are probably other > creative ways in which inline asm might rely on the specific pairing. > Hi Mans, Either that

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:

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 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()