Bug 107190 - [aarch64] regression with optimization -fexpensive-optimizations
Summary: [aarch64] regression with optimization -fexpensive-optimizations
Status: UNCONFIRMED
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 13.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: missed-optimization
Depends on:
Blocks:
 
Reported: 2022-10-09 10:33 UTC by vfdff
Modified: 2023-05-19 01:22 UTC (History)
1 user (show)

See Also:
Host:
Target: aarch64
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments
testcase (279 bytes, text/plain)
2023-05-19 01:22 UTC, Andrew Pinski
Details

Note You need to log in before you can comment on or make changes to this bug.
Description vfdff 2022-10-09 10:33:16 UTC
This case is simplify from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107090, and we can see that the codegen of function `test_m` has some regression with optimization -fexpensive-optimizations, https://gcc.godbolt.org/z/zbKrEox4j

This is because the pass 208t.widening_mul is controlled by -fexpensive-optimizations (default on at -O3), it conversion

```
  m_12 = m_9 + m1_10;
  if (m1_10 > m_12)
```
into

```
  _17 = .ADD_OVERFLOW (m_9, m1_10);
  m_12 = REALPART_EXPR <_17>;
  _18 = IMAGPART_EXPR <_17>;
  if (_18 != 0)``

```
Comment 1 Andrew Pinski 2022-10-10 16:54:43 UTC
(In reply to vfdff from comment #0)
> This case is simplify from
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107090, and we can see that the
> codegen of function `test_m` has some regression with optimization
> -fexpensive-optimizations, https://gcc.godbolt.org/z/zbKrEox4j
> 
> This is because the pass 208t.widening_mul is controlled by
> -fexpensive-optimizations (default on at -O3), it conversion
> 
> ```
>   m_12 = m_9 + m1_10;
>   if (m1_10 > m_12)
> ```
> into
> 
> ```
>   _17 = .ADD_OVERFLOW (m_9, m1_10);
>   m_12 = REALPART_EXPR <_17>;
>   _18 = IMAGPART_EXPR <_17>;
>   if (_18 != 0)``

This should always be better. If ifcvt.cc does not handle this case, then it should be improved.
Comment 2 Andrew Pinski 2022-10-10 17:31:02 UTC
I think it is the expansion of the add with overflow causing things to be worse.
(insn 16 15 17 (set (reg:DI 102 [ _17+8 ])
        (const_int 0 [0])) -1
     (nil))

(insn 17 16 18 (parallel [
            (set (reg:CC_C 66 cc)
                (compare:CC_C (plus:DI (reg:DI 109 [ m ])
                        (reg:DI 111 [ m1 ]))
                    (reg:DI 109 [ m ])))
            (set (reg:DI 112)
                (plus:DI (reg:DI 109 [ m ])
                    (reg:DI 111 [ m1 ])))
        ]) -1
     (nil))

(jump_insn 18 17 19 (set (pc)
        (if_then_else (ltu (reg:CC_C 66 cc)
                (const_int 0 [0]))
            (label_ref 21)
            (pc))) -1
     (int_list:REG_BR_PROB 536868 (nil)))

(jump_insn 19 18 20 (set (pc)
        (label_ref 23)) -1
     (nil))

(barrier 20 19 21)

(code_label 21 20 22 3 (nil) [0 uses])

(insn 22 21 23 (set (reg:DI 102 [ _17+8 ])
        (const_int 1 [0x1])) -1
     (nil))

(code_label 23 22 24 2 (nil) [0 uses])


I don't see why we need to expand to a jump here rather than a cset?
I think there is another bug about this already too.
Comment 3 Andrew Pinski 2023-05-19 01:22:52 UTC
Created attachment 55113 [details]
testcase