search for: beqz

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

Hello All. On a particular target the back-end generates an instruction like: beqz      r2, "$BB0_-1"   Is it a back-end specific issue? Could someone please help me figure out how this gets resolved? What confuses me is, all other branches are correctly labelled and resolved!  Thanks. Girish. -------------- next part -------------- An HTML attachment was scrubbed......

...H: converted to ########################## beq a0, a1, SKIP_J j FAR_BRANCH SKIP_J: … FAR_BRANCH: I found there is a target hook, relaxInstruction, that tries to achieve the similar goal. However, the target hook only replaces one MCInst with another one with a larger branch range. For example, c.beqz will be converted to beq in the RISC-V backend if the fixup value is out of range. There seems no target hook to convert one MCInst to a complex pattern in LLVM MC. Do I miss something obvious? I found there is a target hook, finishLayout, to manipulate the code generated. Does it make sense to im...

...AR_BRANCH > SKIP_J: > … > FAR_BRANCH: > > I found there is a target hook, relaxInstruction, that tries to > achieve the similar goal. However, the target hook only replaces > one MCInst with another one with a larger branch range. For > example, c.beqz will be converted to beq in the RISC-V backend if > the fixup value is out of range. There seems no target hook to > convert one MCInst to a complex pattern in LLVM MC. Do I miss > something obvious? > > I found there is a target hook, finishLayout, to manipulate the...

May be you have branched to a BB which has been deleted. On 24 January 2012 20:16, girish gulawani <girishvg at yahoo.com> wrote: > > Hello All. > On a particular target the back-end generates an instruction like: > beqz r2, "$BB0_-1" > > Is it a back-end specific issue? Could someone please help me figure out > how this gets resolved? What confuses me is, all other branches are > correctly labelled and resolved! > > Thanks. > Girish. > > > ______________________________...

...using scalars. long a, b; long fn1(); long fn2() { long c = a, d = c; for (; b;) { long e = fn1(); d = d + e; } long f = d - c; return f; } For instance in RISC-V we emit something like this but other backends like ARM or X86 show the same behaviour. add s0, zero, s2 # ← copy beqz a0, .LBB0_3 # %bb.1: # %for.body.preheader add s0, zero, s2 # ← not needed .LBB0_2: # %for.body Has anyone encountered a similar issue like this in the past? We are looking into removing these copies with a post RA pass to address the...

...2 different IR, I got the same asm code. The following is the asm code which are mips like: (NOTE: $rx indicates a 32 bits register x, #x indicates constant, subri $r3, $r2, #32 means r3 = 32 - r2, r0, r1 contain the first 64 bits parameter which contains %u, r2 contains the second parameter %b) beqz $r2,83f6 <__ashldi3+0x2a> subri $r3,$r2,#32 blez $r3,83fa <__ashldi3+0x2e> sll $r1,$r1,$r2 srl $r3,$r0,$r3 or $r3,$r3,$r1 sll $r1,$r0,$r2 movi $r2,#0 mov $r0,$r1 or $r1,$r3,$r2 ret $lp ret $lp subri $r3,$r3,#0 movi $r1,#0 sll $r3,$r0,$r3 The above asm code is tested ok in little endian...

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

...his? Best regards, Girish. May be you have branched to a BB which has been deleted. > > >On 24 January 2012 20:16, girish gulawani <girishvg at yahoo.com> wrote: > > >> >>Hello All. >>On a particular target the back-end generates an instruction like: >>beqz      r2, "$BB0_-1" >> >>  >>Is it a back-end specific issue? Could someone please help me figure out how this gets resolved? What confuses me is, all other branches are correctly labelled and resolved!  >> >> >>Thanks.Girish. >> >> >>_...

...t; code. > The following is the asm code which are mips like: > (NOTE: $rx indicates a 32 bits register x, #x indicates constant, subri > $r3, $r2, #32 means r3 = 32 - r2, > r0, r1 contain the first 64 bits parameter which contains %u, r2 contains > the second parameter %b) > > beqz $r2,83f6 <__ashldi3+0x2a> > subri $r3,$r2,#32 > blez $r3,83fa <__ashldi3+0x2e> > sll $r1,$r1,$r2 > srl $r3,$r0,$r3 > or $r3,$r3,$r1 > sll $r1,$r0,$r2 > movi $r2,#0 > mov $r0,$r1 > or $r1,$r3,$r2 > ret $lp > ret $lp > subri $r3,$r3,#0 > movi $r1,#0...

...a, d = c; > for (; b;) { > long e = fn1(); > d = d + e; > } > long f = d - c; > return f; > } > > For instance in RISC-V we emit something like this but other backends like > ARM or X86 show the same behaviour. > > add s0, zero, s2 # ← copy > beqz a0, .LBB0_3 > # %bb.1: # %for.body.preheader > add s0, zero, s2 # ← not needed > .LBB0_2: # %for.body > > Has anyone encountered a similar issue like this in the past? > > We are looking into removing these copies w...

...ibc/arch/mips64/syscall.S b/usr/klibc/arch/mips64/syscall.S new file mode 100644 index 0000000..cca0db2 --- /dev/null +++ b/usr/klibc/arch/mips64/syscall.S @@ -0,0 +1,15 @@ +#include <machine/asm.h> +#include <asm/unistd.h> + + .set noreorder + +LEAF(__syscall_common) + syscall + beqz a3, 1f + # sw is actually two instructions; the first one goes + # in the branch delay slot + # XXX: Break this up manually; as it is now it generates warnings. + sw v0, errno + li v0, -1 +1: jr ra + END(__syscall_common) diff --git a/usr/klibc/arch/mips64/sysst...

....S b/usr/klibc/arch/mips/syscall.S new file mode 100644 index 0000000..9f308df --- /dev/null +++ b/usr/klibc/arch/mips/syscall.S @@ -0,0 +1,16 @@ +#include <asm/asm.h> +#include <asm/regdef.h> +#include <asm/unistd.h> + + .set noreorder + +LEAF(__syscall_common) + syscall + beqz a3, 1f + # sw is actually two instructions; the first one goes + # in the branch delay slot + # XXX: Break this up manually; as it is now it generates warnings. + sw v0, errno + li v0, -1 +1: jr ra + END(__syscall_common) diff --git a/usr/klibc/arch/mips/sysstub...

Hi, Is the http://xenbits.xensource.com/linux-2.6-xen.hg tree still being updated? if not, what''s the preferred Linux tree to track that has all of the Xen bits? Thanks, Muli _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

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: