[llvm-bugs] [Bug 49930] New: [Meta] Missed combines using freeze

[via llvm-bugs]

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

            Bug ID: 49930
           Summary: [Meta] Missed combines using freeze
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: llvm-dev at redking.me.uk
                CC: david.bolvansky at gmail.com, lebedev.ri at gmail.com,
                    llvm-bugs at lists.llvm.org, nunoplopes at sapo.pt,
                    spatel+llvm at rotateright.com
        Depends on: 44136

Now that we have the freeze instruction (and we really want to get rid of
undef), we should be more willing to perform folds that introduce freeze.

Part of this is a general apprehension about using freeze, and also we need to
decide how freeze counts in the 'is this simpler or not' metric that we use for
InstCombine combine rules.

For example, https://reviews.llvm.org/D100211 [Bug #44136], proposed the fold:

define i1 @src(i8 %a, i8 %b) {
  %n = xor i8 %a, -1
  %o = and i8 %n, %b
  %c = icmp eq i8 %o, 0
  ret i1 %c
}

define i1 @tgt(i8 %a, i8 %b) {
  %aa = freeze i8 %a
  %o = or i8 %aa, %b
  %c = icmp eq i8 %o, %aa
  ret i1 %c
}

The freeze is necessary for the fold to be valid, but means we don't reduce the
instruction count (but does freeze count as an instruction in the same way?).
And some were worried about freeze preventing later folds from occurring.


Referenced Bugs:

https://bugs.llvm.org/show_bug.cgi?id=44136
[Bug 44136] Missed optimization: bitwise OR
-- 
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/20210412/6693ee48/attachment-0001.html>