similar to: question on analyzeBranch and getFallThrough

On Tue, Oct 18, 2011 at 4:31 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > > On Oct 18, 2011, at 3:07 PM, Chandler Carruth wrote: > > On Tue, Oct 18, 2011 at 2:59 PM, Cameron Zwarich <zwarich at apple.com>wrote: > >> I think this should really live as a CodeGen pass. Is there any good >> reason to make it an IR pass? >> > > So, as it

On Oct 18, 2011, at 5:22 PM, Chandler Carruth wrote: >> As for why it should be an IR pass, mostly because once the selection dag runs through the code, we can never recover all of the freedom we have at the IR level. To start with, splicing MBBs around requires known about the terminators (which we only some of the time do), and it requires re-writing them a touch to account for the

On Tue, Oct 18, 2011 at 6:58 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > > On Oct 18, 2011, at 5:22 PM, Chandler Carruth wrote: > > As for why it should be an IR pass, mostly because once the selection dag >> runs through the code, we can never recover all of the freedom we have at >> the IR level. To start with, splicing MBBs around requires known about

On Tue, Oct 18, 2011 at 2:59 PM, Cameron Zwarich <zwarich at apple.com> wrote: > On Oct 18, 2011, at 2:53 AM, Chandler Carruth wrote: > > > Hello, > > > > I'm working on basic-block placement optimizations based on branch > probability information. I've run into a stumbling block though. One of the > existing passes to do this, essentially a dead pass

On Oct 18, 2011, at 3:07 PM, Chandler Carruth wrote: > On Tue, Oct 18, 2011 at 2:59 PM, Cameron Zwarich <zwarich at apple.com> wrote: > I think this should really live as a CodeGen pass. Is there any good reason to make it an IR pass? > > So, as it happens, I was *completely* wrong here. CodeGen correctly preserves the ordering of blocks from IR, *unless* it can do folding,

On Oct 19, 2011, at 5:50 AM, Chandler Carruth wrote: > Ok, wow that wasn't hard at all. Awesome ;-) > This is still *very* much a rough draft, but it's probably better to review that the previous patch. One big caveat, I know I have an iteration bug in here somewhere that is inf-looping. Just ran out of steam debugging it, will pick it back up again later today to shake it out.

Evan, et al., I've come across a small issue when using the if conversion pass in PPC to generate conditional returns. Here's a small example: ** Before if conversion ** BB#0: derived from LLVM BB %entry %R3<def> = LI 0 %CR0<def> = CMPLWI %R3, 0 BCC 68, %CR0, <BB#3> Successors according to CFG: BB#3(16) BB#1(16) BB#1: derived from LLVM BB

Hi, guys, I compiled a subroutine with -O2, and llvm backend produced codes like: ################################################################## LBB0_32: ... R31 = -1 R20 = R31 * R20; .... bnz R2, LBB0_34 LBB0_31: ... b LBB0_34 LBB0_33: # weird basic block? R20 = R5 LBB0_34: ....

On Wed, Oct 19, 2011 at 3:24 AM, Chandler Carruth <chandlerc at google.com>wrote: > On Tue, Oct 18, 2011 at 6:58 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > >> >> On Oct 18, 2011, at 5:22 PM, Chandler Carruth wrote: >> >> As for why it should be an IR pass, mostly because once the selection >>> dag runs through the code, we can never

Hi Yang, > bnz R2, LBB0_34 > > I do not have any clue what happens when compiling with -O2. > Can someone make a suggestion? Is the "bnz" instruction marked "isBarrier" in your TableGen files? If so, that would mean LLVM considers fallthrough impossible and decides it can move LBB0_33 around at will. It's still very odd that it thinks it can put it

On Oct 19, 2011, at 7:56 AM, Jakob Stoklund Olesen wrote: >> This is still *very* much a rough draft, but it's probably better to review that the previous patch. One big caveat, I know I have an iteration bug in here somewhere that is inf-looping. Just ran out of steam debugging it, will pick it back up again later today to shake it out. > > Some random notes: > > - Please

On Tue, Jan 10, 2017 at 2:31 AM, Peter A Jonsson <pj at sics.se> wrote: > Hi Kyle, > > my apologies for mailing you directly but it seems new user creation is > disabled on the llvm bugzilla. > > We sometime lose edges during IfConversion of diamonds and it’s not > obvious how to reproduce on an upstream target. The documentation for > HasFallThrough says *may*

Hi all, I was trying to implement an obfuscation tool for C-code on the basis of LLVM. I got a prototype of the simple obfuscation transformation which converting control flow graph to something like a state machine. I am not sure I will have time to work on extending further this tool with new transformations like opaque predicates and decided to put here source code I have by now with hope

  Hi Aries. Thanks very much! Precisely this is the situation! There're two consecutive branches (br1cond and br2uncond). Inside of AnalyzeBranch, there's an opcode swap of br2uncond (ex. j_foward to j_backward). There I do BuildMI (newOpcode) and followed by br2uncond->eraseFromParent(). This results in br1cond loosing it's label/offset. How could I resolve this? Best regards,

Hello Anton. Thanks for the comment. > Precisely this is the situation! There're two consecutive branches (br1cond >> and br2uncond). Inside of AnalyzeBranch, there's an opcode swap of br2uncond >> (ex. j_foward to j_backward). There I do BuildMI (newOpcode) and followed by >> br2uncond->eraseFromParent(). This results in br1cond loosing it's >>

I was hoping to get feedback on this proposal formatted as a patch. I'd like to teach AnalyzeBranch to handle conditional returns on PPC, but the currently documented API for AnalyzeBranch doesn't support it. I propose the following enhancement to the API so that I can teach AnalyzeBranch about conditional return instructions. ---------- Forwarded message ---------- From: Kyle Butt

On Tue, Oct 10, 2017 at 4:48 PM, Friedman, Eli via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 10/9/2017 3:10 AM, Gaël Jobin via llvm-dev wrote: > > Hi all, > > I got a silly bug when compiling our project with the latest Clang. Here's > the outputted assembly: > > tst r3, #255 > strbeq r6, [r7] > ldreq r6, [r4, r6, lsl #2] > strne r6, [r7, #4]

On 11/12/2009, at 10:43 AM, Anton Korobeynikov wrote: > Hi, Chris > >> That is target independent code, so you should not put sparc specific changes there. It sounds like one of the sparc-specific target hooks is wrong. > Since sparc does not provide any hooks for operation of branches (e.g. > AnalyzeBranch and friends) it might be possible that generic codegen > code is

> Precisely this is the situation! There're two consecutive branches (br1cond > and br2uncond). Inside of AnalyzeBranch, there's an opcode swap of br2uncond > (ex. j_foward to j_backward). There I do BuildMI (newOpcode) and followed by > br2uncond->eraseFromParent(). This results in br1cond loosing it's > label/offset. How could I resolve this? Your code is broken.

Hi, Chris > That is target independent code, so you should not put sparc specific changes there.  It sounds like one of the sparc-specific target hooks is wrong. Since sparc does not provide any hooks for operation of branches (e.g. AnalyzeBranch and friends) it might be possible that generic codegen code is broken in absence of these hooks. -- With best regards, Anton Korobeynikov Faculty