Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[x86] unconditional branch not removed in codegen #1572

Closed
lattner opened this issue Feb 14, 2007 · 2 comments
Closed

[x86] unconditional branch not removed in codegen #1572

lattner opened this issue Feb 14, 2007 · 2 comments
Labels
bugzilla Issues migrated from bugzilla code-quality llvm:codegen

Comments

@lattner
Copy link
Collaborator

lattner commented Feb 14, 2007

Bugzilla Link 1200
Resolution FIXED
Resolved on Feb 22, 2010 12:42
Version trunk
OS All
Attachments testcase

Extended Description

The attached LLVM code has an uncond branch that isn't removed by branch folding:

_main_bb_2E_i9_2E_i_2E_i932_2E_ce:
subl $28, %esp
movl %esi, 24(%esp)
movl %edi, 20(%esp)
movl 36(%esp), %esi
movl 32(%esp), %eax
jmp LBB1_6 #bb.i9.i.i932.ce
...
LBB1_6: #bb.i9.i.i932.ce
movl (%eax), %edi
movl L_outfile$non_lazy_ptr, %eax
movl (%eax), %eax

The entry block has a single successor, and LBB1_6 has a single predecessor, so branch folding should
merge them.

-Chris
@llvmbot
Copy link
Collaborator

llvmbot commented Feb 14, 2007

By the time branch folding is reached the switch statement has been broken into a binary tree of
compares. The target block of the unconditional branch (LBB1_6) thus has two successors, one of which is
a fallthrough; the branch folder doesn't move the block up in that case:
// If the prior block doesn't fall through into this block, and if this
// block doesn't fall through into some other block, see if we can find a
// place to move this block where a fall-through will happen.
So that's why. The comment doesn't explain why, but obviously hoisting such a block gains no branches
in itself. If repeated enough times, however, you eventually get to a fallthrough that returns, and hoisting
that will gain a branch (in this case).

@llvmbot
Copy link
Collaborator

llvmbot commented Feb 17, 2007

Fixed.
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070212/044660.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070212/044659.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070212/044661.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070212/044662.html

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 3, 2021
troelsbjerre pushed a commit to troelsbjerre/llvm-project that referenced this issue Jan 10, 2024
@jasonmolenda
debguserver's type sniffer to only treat .app things that end in .app (…
c06edc0 
…llvm#1572)

On an iOS device, if debugserver is left to figure out how to launch
the binary provided, it looks at the filename to see if it contains
".app" and asks FrontBoard to launch it.  However, if this is actually
a command line app with the characters ".app" in the name, it would
end up trying to launch that via the FrontBoard calls even though it
needed to be launched via posix_spawn.  For instance, a command line
program called com.application.tester.

Jim suggested this patch where we only send binaries that end in ".app"
to FrontBoard.

Often debugsever is invoked with a --launch command line argument to
specify the launch method, and none of this code is hit in that
instance.

<rdar://problem/65297100>

(cherry picked from commit abf546d)
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bugzilla Issues migrated from bugzilla code-quality llvm:codegen
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@lattner @llvmbot