Skip to content

Missed optimization opportunity with duplicated conditional (JumpThreading?) #8480

Open
@llvmbot

Description

@llvmbot
Bugzilla Link 8108
Version trunk
OS All
Attachments missed.ll
Reporter LLVM Bugzilla Contributor

Extended Description

See the attached .ll files. In particular, note this snippet:

lor.rhs.i:
%cmp9.i = icmp eq i32 %tmp2, 16
br label %_Z16sparc_floating_pPK4type.exit

_Z16sparc_floating_pPK4type.exit:
%call19 = phi i1 [ true, %sw.bb.i ], [ %cmp9.i, %lor.rhs.i ], [ true, %sw.bb.i ]
%cmp = icmp eq i32 %tmp2, 16
%or.cond = and i1 %call19, %cmp
br i1 %or.cond, label %if.end18, label %sw.bb.i24

Notice that the comparison of %tmp2 with 16 is repeated. If this edge were to be threaded by JumpThreading, GVN would pick up the duplication and get rid of it. However, because we can't actually determine a value for the comparison JumpThreading does not currently choose to thread this edge.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions