[llvm-bugs] [Bug 38079] New: [x86] Esoteric macro-fusion opportunity: converting jumps to fuseable conditional branches

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=38079

            Bug ID: 38079
           Summary: [x86] Esoteric macro-fusion opportunity: converting
                    jumps to fuseable conditional branches
           Product: new-bugs
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: jari at kirma.fi
                CC: llvm-bugs at lists.llvm.org

This is just a wild idea. In short, Intel macro-fusion accepts any conditional
branch with and/test instructions, for instance the following:

...
and ...
jnc ...

Which is, as carry flag is always cleared by and, the same as:

and ...
[... reorderable instructions ...]
jmp ...

but some forms of it can be macro-fused as above, thus reducing ops from two to
one.

I understand that this optimization seems odd. Multiple issues arise:

- Branch predictor load is increased
- Conditional branches may be easily mispredicted if they are not in hot loops,
and mispredictions quickly eliminate the benefit
- If code is in a hot loop, it has lower likelihood of an unconditional jump
(my guess).

Still, I want to bring up this esoteric corner case optimization.

This method can be applied also to add, sub, adc and sbc if an invariant is
known to hold; for instance, jnc can be used similarly to example above if
result is known not to set carry bit (that is, it never wraps around the
unsigned integer). Also, if result is known to be non-zero, jnz can be used in
the case of inc/dec.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20180706/217d6286/attachment.html>