similar to: [LLVMdev] Support of register pair for 64-bit data?

Displaying 20 results from an estimated 2000 matches similar to: "[LLVMdev] Support of register pair for 64-bit data?"

2013 Mar 13
0
[LLVMdev] Problems with 64-bit register operands of inline asm on ARM
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
2013 Mar 13
5
[LLVMdev] 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 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
2013 Mar 13
0
[LLVMdev] Problems with 64-bit register operands of inline asm on ARM
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*
2013 Mar 13
3
[LLVMdev] Problems with 64-bit register operands of inline asm on ARM
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
2013 Mar 13
0
[LLVMdev] 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) 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
2012 Sep 24
0
[LLVMdev] Proposal: New DAG node type for reciprocal operation
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,
2012 Sep 21
2
[LLVMdev] Proposal: New DAG node type for reciprocal operation
--- 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
2012 Sep 20
0
[LLVMdev] Proposal: New DAG node type for reciprocal operation
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
2014 Mar 12
3
[LLVMdev] [ARM] [PIC] optimizing the loading of hidden global variable
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
2014 Jun 20
2
[LLVMdev] [AArch64] Question about far call
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
2014 Mar 14
2
[LLVMdev] [ARM] [PIC] optimizing the loading of hidden global variable
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
2012 Sep 20
2
[LLVMdev] Proposal: New DAG node type for reciprocal operation
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
2014 Mar 14
2
[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
2015 Sep 29
2
Fwd: buildbot failure in LLVM on clang-ppc64-elf-linux2
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
2015 Sep 29
3
Fwd: buildbot failure in LLVM on clang-ppc64-elf-linux2
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
2014 Jul 17
2
[LLVMdev] [compiler-rt] CMake bug in building ARM builtins library
On 7/16/14, 6:09 PM, sgundapa wrote: > I see a couple of issues here. > > If I include .S files for ARM, the –no-integrated-as path complains about > Assembler errors. > > The integrated-as path works fine though. > These are very likely just differences between the old ARM assembler syntax and the new 'Unified' syntax. Can you use an assembler that accepts UAL
2018 Dec 04
2
Incorrect placement of an instruction after PostRAScheduler pass
Hi, I’m facing a crash issue (--target=arm-linux-gnueabi -march=armv8-a+crc -mfloat-abi=hard) and debugging the problem, I found that an intended branch was not taken due to bad code generation after the Post RA Scheduler pass. A CMPri instruction after an INLINEASM block (which inturn contains a cmp, bne instruction) is being moved before the INLINEASM block incorrectly resulting in two
2019 Jul 12
2
[cfe-dev] ARM float16 intrinsic test
Hi, I do not get your result. Do I miss something? $COMP_ROOT/clang++ --target=arm-arm-eabihf -march=armv8.2a+fp16 arm.cpp -S -o - -O3 .text .syntax unified .eabi_attribute 67, "2.09" .eabi_attribute 6, 14 .eabi_attribute 7, 65 .eabi_attribute 8, 1 .eabi_attribute 9, 2 .fpu crypto-neon-fp-armv8 .eabi_attribute 12, 4
2006 Nov 09
3
[LLVMdev] Is this bug in LLVM?
Hello. My name is Seung Jae Lee. I'd like to ask you onething about converting to ARM assembly code. I saved the simplest C code shown in your LLVM webpage as 'hello.c' And I made 'hello.bc' by "$ llvm-gcc hello.c -o hello". In order to make ARM assembly code, I typed "llc -march=arm hello.bc -o hello.arm" But, I met this error. llc: ARMISelDAGToDAG.cpp:73:
2017 Apr 05
2
compiler-rt, v4.0: arm\udivsi3.S broken for division by zero
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