search for: bnez

Hi all, I'm trying to implement the same branch relaxation mechanism implemented in CodeGen in the MC layer of RISCV.   beqz t1, L1   =>   bnez t1, L2   j L1 That's because LLVM does not apply the CodeGen optimizations when compiling directly from assembly code. What I'd like to do would be to add a pass that does that on the MC instructions or at least to find a way to implement this relaxation in the MC assembler. Any suggest...

...16Regs:$r), (Mflo16) ]>; Without the list of instructions feature in the Pattern class, I am forced to make a pseudo that has both the mul and mflo instruction in it. This is a very simple example and some, like for example the conditional move have 3 instructions with sequences like: cmp x,y bnez .+4 move a, b I am able to do all of this just fine with pseudo's but it's not as clean a solution. ________________________________________ From: Sean Silva [silvas at purdue.edu] Sent: Sunday, September 16, 2012 1:09 PM To: Kotler, Reed Cc: Hal Finkel; Anton Korobeynikov; LLVM-Dev ‎[llv...

...5: .cfi_offset 17, -12 $tmp6: .cfi_offset 16, -16 addu $16, $2, $25 move $17, $4 lw $18, %call16(foo)($16) $BB0_1: # %loop # =>This Inner Loop Header: Depth=1 move $25, $18 jalr $25 move $gp, $16 addiu $17, $17, -1 bnez $17, $BB0_1 nop # BB#2: # %exit lw $16, 16($sp) # 4-byte Folded Reload lw $17, 20($sp) # 4-byte Folded Reload lw $18, 24($sp) # 4-byte Folded Reload lw $ra, 28($sp) # 4-byte Folded Reload jr $ra addiu $sp, $sp, 32 w...

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

What have you tried? On Sun, Sep 16, 2012 at 3:34 PM, Kotler, Reed <rkotler at mips.com> wrote: > This Pattern class says it's possible but seems just to not work or maybe I'm using it incorrectly. > > Probably I will go and fix it when I'm done with mips16. > > > ________________________________________ > From: Hal Finkel [hfinkel at anl.gov] > Sent:

This Pattern class says it's possible but seems just to not work or maybe I'm using it incorrectly. Probably I will go and fix it when I'm done with mips16. ________________________________________ From: Hal Finkel [hfinkel at anl.gov] Sent: Sunday, September 16, 2012 10:59 AM To: Anton Korobeynikov Cc: Kotler, Reed; LLVM-Dev ‎[llvmdev at cs.uiuc.edu]‎ Subject: Re: [LLVMdev] Pattern

On 2/5/19 1:27 AM, Philip Reames via llvm-dev wrote: > > On 1/31/19 4:57 PM, Bruce Hoult wrote: >> On Thu, Jan 31, 2019 at 4:05 PM Philip Reames via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >>> Do such architectures frequently have arithmetic operations on the >>> mask registers?  (i.e. can I reasonable compute a conservative >>> length

On 10 May 2014, at 13:53, Tim Northover <t.p.northover at gmail.com> wrote: > It doesn't make sense for everything though, particularly if you want > target-specific IR to simply not exist. What would you map ARM's > "ldrex" to on x86? This isn't a great example. Having load-linked / store-conditional in the IR would make a number of transforms related to

...ments in v8-v15 to v16-v23 > vsd.v v16, (a1) # Store vector of 64b > slli a5, a4, 3 # multiply AVL by element size 8 bytes > add a1, a1, a5 # Bump pointer dst > sub a0, a0, a4 # subtract AVL from n to get remaining count > bnez a0, foo # Any more? > ret > > The alternative of course is to set up for 64 bit elements at the > outset, let the two vlw.v's for a and b widen the 32 bit loads into 64 > bit elements, then do 64x64->64 multiplies. The code would be two > instructions shorter,...

On Fri, Feb 1, 2019 at 1:19 AM Bruce Hoult <brucehoult at sifive.com> wrote: > On Thu, Jan 31, 2019 at 11:53 PM Luke Kenneth Casson Leighton via > llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > --- > > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 > > > > On Thu, Jan 31, 2019 at 10:22 PM Jacob Lifshay

...ck) } +} diff --git a/usr/klibc/arch/mips64/pipe.S b/usr/klibc/arch/mips64/pipe.S new file mode 100644 index 0000000..932fc08 --- /dev/null +++ b/usr/klibc/arch/mips64/pipe.S @@ -0,0 +1,15 @@ +#include <machine/asm.h> +#include <asm/unistd.h> + +LEAF(pipe) + li v0, __NR_pipe + syscall + bnez a3, 1f + sw v0, (a0) + sw v1, 4(a0) + li v0, 0 + b 2f +1: sw v0, errno + li v0, -1 +2: jr ra + END(pipe) diff --git a/usr/klibc/arch/mips64/setjmp.S b/usr/klibc/arch/mips64/setjmp.S new file mode 100644 index 0000000..68eed19 --- /dev/null +++ b/usr/klibc/arch/mips64/setjmp.S @@ -0,0 +1,80 @@ +# +...

.../usr/klibc/arch/mips/pipe.S b/usr/klibc/arch/mips/pipe.S new file mode 100644 index 0000000..02b9405 --- /dev/null +++ b/usr/klibc/arch/mips/pipe.S @@ -0,0 +1,16 @@ +#include <asm/asm.h> +#include <asm/regdef.h> +#include <asm/unistd.h> + +LEAF(pipe) + li v0, __NR_pipe + syscall + bnez a3, 1f + sw v0, (a0) + sw v1, 4(a0) + li v0, 0 + b 2f +1: sw v0, errno + li v0, -1 +2: jr ra + END(pipe) diff --git a/usr/klibc/arch/mips/setjmp.S b/usr/klibc/arch/mips/setjmp.S new file mode 100644 index 0000000..68eed19 --- /dev/null +++ b/usr/klibc/arch/mips/setjmp.S @@ -0,0 +1,80 @@ +# +# arch...

I have updated the klibc patchset based on feedback received. In particular, the patchset has been reorganized so as not to break git-bisect. Additionally, this updates the patch base to 2.6.17-git12 (d38b69689c349f35502b92e20dafb30c62d49d63) and klibc 1.4.8; the main difference on the klibc side is removal of obsolete code. This is also available as a git tree at: