similar to: weak definitions in LTO

Glad to hear you can reproduce it. What I don't know is if this is a linker issue or an LLVM issue. -----Original Message----- From: Rafael Espíndola [mailto:rafael.espindola at gmail.com] Sent: Friday, May 30, 2014 3:58 PM To: Daniel Stewart Cc: LLVM Developers Mailing List Subject: Re: Error with Gold Linker during LTO Sorry, I had understood that the linker was crashing, not the

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,

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

Thanks Peter, this is very useful feedback. I did manage to change the behavior of LinkOnlyNeeded to correctly import all variables with AppendingLinkage. In fact, I discovered that there was already something fishy. A variable with AppendingLinkage would get imported correctly from the source module if the destination module already contained a definition for that variable and wouldn't be

+nick and rafael, who seem to a lot about linkage. I made the following claim on llmv-commits [1]: On 2014 Mar 3, at 15:01, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > Giving these functions internal linkage allows them to be dead-stripped. Is that even correct? This is the assumption I’ve been working under, but I’m not sure where I got it from. It seems like the

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

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

Yes, it's a bug. Please review https://reviews.llvm.org/D31716 On 4/5/2017 3:50 AM, Renato Golin wrote: > On 21 March 2017 at 18:32, Peter Jakubek via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> I think the current implementation for the call "bl __aeabi_idiv0" in >> builtins\arm\udivsi3.S is broken. >> At least for the case that __aeabi_idiv0

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

Thanks for the hindsight. I am currently working on a patch/potential fix which introduces a new Linker::ImportIntrinsicGlobalVariables flag. The patch includes a unit test reproducing the problem. Hopefully, that will help getting more feedback. Note that it might take a while before I am allowed to upload the patch since I need approval from Autodesk Legal department. Cheers, Benoit Benoit

On Fri, Nov 13, 2020 at 11:17 AM David Blaikie <dblaikie at gmail.com> wrote: > > On Fri, Nov 13, 2020 at 11:05 AM Fāng-ruì Sòng <maskray at google.com> wrote: > > > > I got replies from Nick Clifton and Michael Matz: > > https://sourceware.org/pipermail/binutils/2020-November/114116.html > > (and its reply). > > I have mentioned (a) the difficulty

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, 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, There are cases where LLVM is able to detect some UB but clang is not. For example, unsigned int foo(unsigned int x) { int ret = 0; for(int i = 0; i <= 32; ++i) ret += x >> i; return ret; } When the loop is unrolled, LLVM InstructionSimplify will catch it and return a UNDEF value. How can we let LLVM report some warning message to help developers correct the error?

Adding Peter to comment on the linker resolution issue. >From adding save-temps, it looks like lld and gold are giving different resolutions to the symbols, which is presumably creating this issue: (first file is with lld and second is with gold) $ diff a.out.resolution.txt gold/ 4c4 < -r=a.o,__llvm_profile_raw_version,plx --- > -r=a.o,__llvm_profile_raw_version,l 8,9c8,9 <

> From looking at the code, it seems like LLVM is basically opting MachO into -fvisibility-inlines-hidden all the time, i.e. if the function is linkonce, it's discardable, so mark it hidden to pretend the compiler inlined it and discarded it. However, this isn't conforming, because the addresses of inline functions will no longer compare equal across DSOs. I think there is a nuance, it

> > This scares me a little for linkonce -- there's a minor change to > semantics if the importing module would have linked against a > *different* definition of the same symbol -- but I'm not really > sure it matters much. > > This should not be an issue in practice as it exists non thinLTO compilations too. For instance changing the optimization level of one module

The problem is that ThinLTO is not dropping the non-prevailing definitions, and they end up being emitted into the object file for b.o. $ ../ra/bin/llvm-dis -o - b.o0.0.preopt.bc | grep __llvm_prof $__llvm_profile_raw_version = comdat any $__llvm_profile_filename = comdat any @__llvm_profile_raw_version = constant i64 72057594037927940, comdat @__llvm_profile_filename = constant [19 x i8]

> On 2015-Jul-21, at 15:35, Xinliang David Li <xinliangli at gmail.com> wrote: > > > > This scares me a little for linkonce -- there's a minor change to > semantics if the importing module would have linked against a > *different* definition of the same symbol -- but I'm not really > sure it matters much. > > > > This should not be an issue

Thanks Peter, your patch does fix the reproducer. I filed https://bugs.llvm.org/show_bug.cgi?id=37422 to track this bug. I have no clue on how to resolve the tests - whether further cleanup is required in the code or in the tests. But if Teresa or you cannot get to it, I can, with some help, take a crack at fixing the tests. On Wed, May 9, 2018 at 11:26 AM Peter Collingbourne <peter at