similar to: [LLVMdev] Not enough optimisations in the SelectionDAG phase?

On Apr 24, 2012, at 11:48 PM, Fan Dawei wrote: > For the following code fragment, > > ; <label>:27 ; preds = %27, %entry > %28 = load volatile i32* inttoptr (i64 2149581832 to i32*), align 8 > %29 = icmp slt i32 %28, 0 > br i1 %29, label %27, label %loop.exit > > loop.exit: ; preds = %27

On 04/29/2012 01:19 PM, Evan Cheng wrote: > On Apr 24, 2012, at 11:48 PM, Fan Dawei wrote: > >> For the following code fragment, >> >> ;<label>:27 ; preds = %27, %entry >> %28 = load volatile i32* inttoptr (i64 2149581832 to i32*), align 8 >> %29 = icmp slt i32 %28, 0 >> br i1 %29, label %27, label

Hi Bjorn, could you file a bug on llvm.org/bugs and cc me on it. Thanks, Arnold > So it appears that also the ARM backend has a big problems with sign-extending loads. > > I've compiled the following loop > > short in[]; > int out[]; > int value; > > for (i = 0; i < nr; i++) { > value = in[i]; > if (value>2047) >

Hi Jim, Thanks for reply. I'm sorry I didn't make myself clear enough. The MCInst created by MCDisassembler depends on the instructions defined in td files. These instructions do not have a one to one mapping to ARM instructions. There are usually one or more instructions defined in the td file correspond to one actual ARM instruction. Thanks, David On Thu, Jun 7, 2012 at 1:27 PM, Jim

Hello all, I am looking at the assembly code of a loop body which is created by applying O3 optimization. Here it is: .LBB4_19: @ %for.body.91 @ =>This Inner Loop Header: Depth=1 ldr r0, [r5] mov r1, r8 add r0, r0, r7 vldr s0, [r0] mov r0, r6 vcvt.f64.f32 d0, s0 vmov

Ryan Taylor via llvm-dev <llvm-dev at lists.llvm.org> writes: > r0 gets overwritten inside the loop (assuming dst, src, src), is ldr > r0, [r5] needed to initialize r0 for the loop at each iteration? Register allocation should handle that if the load is hoisted. I'm with the others. The printf is the most likely culprit. -0David > On Thu, Mar 28, 2019

Here's an example using the gcc toolchain for embedded 32 bit RISC-V (my HiFive1 board): #include <stdio.h> int foo(int i){ if (i < 100){ printf("%d\n", i); } return i; } int main(){ foo(10); return 0; } After compiling to a .o with -O2 -march=RV32IC we get (just looking at foo) 00000000 <foo>: 0: 1141 addi sp,sp,-16

Hi Tim, Thanks a lot for your help! I'm very grateful. libc.so is a prelinked library, I'll build a non-prelinked one and have another try. I'm now at the start of a binary translation project. I want to convert ARM binary code [*] to llvm ir, which is then translated to binary for our mips like architecture. That's why I'm looking for a decoder for ARM binary. The

That depends on how you define "one ARM instruction." It's not a clear cut thing. For example, is "add r1, r2, r3" the same ARM instruction as "add r1, r2, #4"? What is a distinct instruction and what's a variant encoding of the same instruction is often entirely a matter of convenience. -Jim On Jun 8, 2012, at 6:40 AM, Fan Dawei <fandawei.s at

Hi, Does lld support linker relaxation that may shrink code size? As far as I see lld seems to assume that the content of input sections to be fixed other than patching up relocations, but I believe some targets may benefit the extra optimization opportunity with relaxation. Specifically, I'm currently working on adding support for RISC-V in lld, and RISC-V heavily relies on linker relaxation

On 2008-06-11, at 13:16, Gary Benson wrote: > Duncan Sands wrote: > >> Can you please attach IR which can be compiled to an executable >> (and shows the problem). > > I've been generating functions using a builder and then compiling > them with ExecutionEngine::getPointerToFunction(). Is there some way > I can get compilable IR from that?

Duncan Sands wrote: > Can you please attach IR which can be compiled > to an executable (and shows the problem). I've been generating functions using a builder and then compiling them with ExecutionEngine::getPointerToFunction(). Is there some way I can get compilable IR from that? Cheers, Gary -- http://gbenson.net/

I didn't have Mips board. I compile as the commands and check the asm output as below. 1. Question: The distance of caller arg[4] and arg[5] is 4 bytes. But the the callee get every arg[] by 8 bytes offset (arg_ptr1+8 or arg_ptr2+8). I assume the #BB#4 and #BB#5 are the arg_ptr which is the pointer to access the stack arguments. 2. Question: Stack memory 28($sp) has no initial value. If

By the way, since this is an optional code relaxation, we can think about it later. The first thing I would do is to add RISC-V support to lld without code shrinking relaxations, which I believe is doable by at most a few hundreds lines of code. On Wed, Jul 12, 2017 at 3:21 AM, Rui Ueyama <ruiu at google.com> wrote: > On Tue, Jul 11, 2017 at 9:14 PM, Bruce Hoult via llvm-dev < >

Hi Tim, Thanks a lot for the reply. I tested libc.so which is a shared library. llvm-objdump also report some disassemble errors. Could you please tell me more about $a, $t and $d symbols? How these symbols are used to define different regions? Where I can find this symbols in ELF object file? Thanks, David I'm now try to find a decoder of ARM instructions in oder On Thu, Jun 7, 2012

Does it make a difference if you give the "-target" option to clang? $ clang -target mips-linux-gnu ch8_3.cpp -o ch8_3.bc -emit-llvm -c The .s file generated this way looks quite different from the one in your email. On Tue, Feb 19, 2013 at 5:06 PM, Jonathan <gamma_chen at yahoo.com.tw> wrote: > I didn't have Mips board. I compile as the commands and check the asm >

On Jun 7, 2012, at 7:53 AM, Fan Dawei <fandawei.s at gmail.com> wrote: > Hi Tim, > > Thanks a lot for your help! I'm very grateful. > > libc.so is a prelinked library, I'll build a non-prelinked one and have another try. > > I'm now at the start of a binary translation project. I want to convert ARM binary code [*] to llvm ir, which is then translated to

Hello Evan and Robert I have been investigating the unexpected test failures from the ARM nightly builders in order to get a better picture why the ARM backend don't pass the whole testsuite: I have run the failing tests manually on my arm board and can now categorize most of the thirteen unexpected CodeGen failures in four categories: 1. llvm don't lower MVT::i64 properly on arm

Hi All, I work on a backend for a target similar to Mips, where large immediates are loaded into registers with 2 instructions, 1 to load the MSBits and 1 to load the LSBits. I've noticed a recurring pattern where, despite low register pressure, these constants will be rematerialized in every iteration of a loop, rather than being hoisted. Here's an example using the

I need to be able to emit .globl for the soft float routines used by mips16. The routines are called but there is no .globl definition for them. How can I do this? Background: I have a strange issue that I encountered with mips16 hard float. Part of mips16 hard float is to emit calls to runtime routines with the same signature as usual soft float routines, except that they are implemented