search for: weimingz

--- 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 suspect a target specific node wouldn't be necessary and the patterns could be matched directly. -Jim Yes, a target specific node is no...

...- On Thu, 9/20/12, Jim Grosbach <grosbach at apple.com<mailto:grosbach at apple.com>> wrote: From: Jim Grosbach <grosbach at apple.com<mailto:grosbach at apple.com>> Subject: Re: [LLVMdev] Proposal: New DAG node type for reciprocal operation To: "Weiming Zhao" <weimingz at codeaurora.org<mailto:weimingz at codeaurora.org>> Cc: llvmdev at cs.uiuc.edu<mailto: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 suspect a target specific node wouldn't be necessary and t...

...gt;, Piotr Padlewski <prazek at google.com>, Reid Kleckner <rnk at google.com>, Richard Trieu <rtrieu at google.com>, Sanjay Patel <spatel at rotateright.com>, Sanjoy Das <sanjoy at playingwithpointers.com>, Sean Silva <chisophugis at gmail.com>, Weiming Zhao <weimingz at codeaurora.org> Cc: gkistanova at gmail.com The Buildbot has detected a new failure on builder clang-ppc64-elf-linux2 while building cfe. Full details are available at: http://lab.llvm.org:8011/builders/clang-ppc64-elf-linux2/builds/19559 Buildbot URL: http://lab.llvm.org:8011/ Buildslav...

...64-integer type, it *probably* needs paired GPR. Weiming Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation From: Renato Golin [mailto:renato.golin at linaro.org] Sent: Wednesday, March 13, 2013 10:03 AM To: Måns Rullgård Cc: LLVM Dev; weimingz at codeaurora.org Subject: Re: Problems with 64-bit register operands of inline asm on ARM 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)...

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

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

...Reid Kleckner < > > rnk at google.com >, Richard Trieu < rtrieu at google.com >, Sanjay Patel > > < spatel at rotateright.com >, Sanjoy Das < > > sanjoy at playingwithpointers.com >, Sean Silva < chisophugis at gmail.com > > >, Weiming Zhao < weimingz at codeaurora.org > > > Cc: gkistanova at gmail.com > > > > > > The Buildbot has detected a new failure on builder > > clang-ppc64-elf-linux2 while building cfe. > > Full details are available at: > > http://lab.llvm.org:8011/builders/clang-ppc64-elf-l...

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

...akob, do you have any suggestions? Thanks, Weiming Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -----Original Message----- From: Måns Rullgård [mailto:mans at mansr.com] Sent: Wednesday, March 13, 2013 6:43 AM To: llvmdev at cs.uiuc.edu Cc: weimingz at codeaurora.org; renato.golin at linaro.org Subject: Problems with 64-bit register operands of inline asm on ARM 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...

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

...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 each GV and 2 instructions to get the >> address: >> >> GCC does this only for the first GV. The rest GV address are computed >> directly: > > This looks like it would be the job of lib/Transforms/G...

...t how to do basic profiling for PGO. MartinO -----Original Message----- From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Jonathan Roelofs via llvm-dev Sent: 06 September 2017 22:27 To: Friedman, Eli <efriedma at codeaurora.org>; Vedant Kumar <vsk at apple.com>; weimingz at codeaurora.org; llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] Using source-based code coverage on baremetal On 9/5/17 7:55 PM, Friedman, Eli via llvm-dev wrote: > > Areas that required LLVM changes: > > 1. The copy of libclangrt_profile.a for the target....

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

Hi all, I think using code coverage on baremetal has come up once or twice on llvmdev, but I don't think anyone has actually written up how the workflow works, or what issues come up.  This description is based on work done together with my colleague Weiming Zhao. By "baremetal" here, I mean an embedded environment without an operating system.  We specifically used a ARM target

Hi, I'm wondering if LLVM plans to support paired register constraints for 64-bit data. Take ARM for example, the atomic i64 value read/write instuctions: ldrexd/strexd, require aligned register pairs (even/odd). Currently, in LLVM ARM (ARMISelDAGToDAG.cpp), ldrexd/strexd get hard coded registers (R0,R1) before register allocation via intrinsic. It would be neater if there is a

Hi, Given a function like x < 0 ? 0 : x We can lower it to bic x, x, asr 31 because we can test if CC==LT && RHS==TrueVal==0 && LHS==FalseVal Further, give a function x > 255 ? 255 : (x < 0 ? 0 :x), we should lower it to: usat x, #8 However, things become more complicated if we have ((x < 0 ? 0 :x) << n ) & mask ... Because it will first be converted to x