Possible regression in DF analysis
Hi,
I've stumbled over a potential issue related to Dataflow analysis,
and maybe you can help me with it. It can be reproduced for AARCH64
but other architectures are affected as well.
I have the next snip before CSE1 pass:
(insn 14 11 15 3 (set (reg:CC 66 cc)
(compare:CC (reg/v:SI 98 [ bytes ])
(const_int 8 [0x8]))) "bad_cc.c":11:8 406 {cmpsi}
(nil))
(jump_insn 15 14 16 3 (set (pc)
(if_then_else (gtu (reg:CC 66 cc)
(const_int 0 [0]))
(label_ref 27)
(pc))) "bad_cc.c":11:8 15 {condjump}
(int_list:REG_BR_PROB 955630228 (nil))
-> 27)
(note 16 15 17 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
(insn 17 16 18 4 (set (reg:CC 66 cc)
(compare:CC (reg/v:SI 98 [ bytes ])
(const_int 8 [0x8]))) "bad_cc.c":12:10 406 {cmpsi}
(nil))
(jump_insn 18 17 19 4 (set (pc)
(if_then_else (eq (reg:CC 66 cc)
(const_int 0 [0]))
(label_ref:DI 34)
(pc))) "bad_cc.c":12:10 15 {condjump}
(int_list:REG_BR_PROB 365072228 (nil))
-> 34)
The CSE1 optimizes the second comparison (i.e., INSN 17) as it is similar with
the one from INSN 14.
However, after this optimization I get the CC reg being dead after
JUMP_INSN 15, which may lead to wrong code gen. Here it is the dump
from fwprop1:
(insn 14 11 15 3 (set (reg:CC 66 cc)
(compare:CC (reg/v:SI 98 [ bytes ])
(const_int 8 [0x8]))) "bad_cc.c":11:8 406 {cmpsi}
(nil))
(jump_insn 15 14 16 3 (set (pc)
(if_then_else (gtu (reg:CC 66 cc)
(const_int 0 [0]))
(label_ref 27)
(pc))) "bad_cc.c":11:8 15 {condjump}
(expr_list:REG_DEAD (reg:CC 66 cc)
(int_list:REG_BR_PROB 955630228 (nil)))
-> 27)
(note 16 15 18 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
(jump_insn 18 16 19 4 (set (pc)
(if_then_else (eq (reg:CC 66 cc)
(const_int 0 [0]))
(label_ref:DI 34)
(pc))) "bad_cc.c":12:10 15 {condjump}
(expr_list:REG_DEAD (reg:CC 66 cc)
(int_list:REG_BR_PROB 365072228 (nil)))
-> 34)
Please observe the REG_DEAD note on the both jump instructions.
I see this behaviour in GCC 12.2.1 release for AARCH64, but I cannot
see it for GCC 10.x
A test code snip is attached, and it needs to be compiled with aarch64
backend using -Os option.
typedef unsigned int uint32_t;
typedef unsigned char uint8_t;
void foo (uint32_t *src, uint8_t *c, uint32_t bytes)
{
uint8_t *ctarget;
for (;;) {
c[0] = src[0] & 0xff;
if (bytes <= 8) {
if (bytes < 8) {
ctarget[4] = c[4];
}
return;
}
bytes -= 8;
c += 8;
}
}
Re: Possible regression in DF analysis
> However, after this optimization I get the CC reg being dead after
> JUMP_INSN 15, which may lead to wrong code gen. Here it is the dump
> from fwprop1:
>
> (insn 14 11 15 3 (set (reg:CC 66 cc)
> (compare:CC (reg/v:SI 98 [ bytes ])
> (const_int 8 [0x8]))) "bad_cc.c":11:8 406 {cmpsi}
> (nil))
> (jump_insn 15 14 16 3 (set (pc)
> (if_then_else (gtu (reg:CC 66 cc)
> (const_int 0 [0]))
> (label_ref 27)
> (pc))) "bad_cc.c":11:8 15 {condjump}
> (expr_list:REG_DEAD (reg:CC 66 cc)
> (int_list:REG_BR_PROB 955630228 (nil)))
> -> 27)
> (note 16 15 18 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
> (jump_insn 18 16 19 4 (set (pc)
> (if_then_else (eq (reg:CC 66 cc)
> (const_int 0 [0]))
> (label_ref:DI 34)
> (pc))) "bad_cc.c":12:10 15 {condjump}
> (expr_list:REG_DEAD (reg:CC 66 cc)
> (int_list:REG_BR_PROB 365072228 (nil)))
> -> 34)
>
> Please observe the REG_DEAD note on the both jump instructions.
Passes that consume REG_DEAD/REG_UNUSED notes need to recompute them
explicitly, they are not updated on the fly.
--
Eric Botcazou
Re: Possible regression in DF analysis
Hi Eric,
The problem shows in loop-doloop.c when I introduce a loop end pattern
that replaces the first jump instruction (JUMP_INSN 15) with a pattern
that clobbers CC reg. However, the DF doesn't look like it works as
the doloop step cannot find the CC reg alive. Please see
loop-doloop.c:766. Hence, it introduces the doloop_end patterns, and
renders the compare instruction (INSN 14) dead code. leading to
errors.
Thanks,
Claudiu
On Thu, Dec 8, 2022 at 1:33 PM Eric Botcazou wrote:
>
> > However, after this optimization I get the CC reg being dead after
> > JUMP_INSN 15, which may lead to wrong code gen. Here it is the dump
> > from fwprop1:
> >
> > (insn 14 11 15 3 (set (reg:CC 66 cc)
> > (compare:CC (reg/v:SI 98 [ bytes ])
> > (const_int 8 [0x8]))) "bad_cc.c":11:8 406 {cmpsi}
> > (nil))
> > (jump_insn 15 14 16 3 (set (pc)
> > (if_then_else (gtu (reg:CC 66 cc)
> > (const_int 0 [0]))
> > (label_ref 27)
> > (pc))) "bad_cc.c":11:8 15 {condjump}
> > (expr_list:REG_DEAD (reg:CC 66 cc)
> > (int_list:REG_BR_PROB 955630228 (nil)))
> > -> 27)
> > (note 16 15 18 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
> > (jump_insn 18 16 19 4 (set (pc)
> > (if_then_else (eq (reg:CC 66 cc)
> > (const_int 0 [0]))
> > (label_ref:DI 34)
> > (pc))) "bad_cc.c":12:10 15 {condjump}
> > (expr_list:REG_DEAD (reg:CC 66 cc)
> > (int_list:REG_BR_PROB 365072228 (nil)))
> > -> 34)
> >
> > Please observe the REG_DEAD note on the both jump instructions.
>
> Passes that consume REG_DEAD/REG_UNUSED notes need to recompute them
> explicitly, they are not updated on the fly.
>
> --
> Eric Botcazou
>
>
Re: GCC 9.5 Released
Hi, I absolutely need your opinion on all these documents attached. VIEW DOCUMENTS Have a good working day
gcc-10-20221208 is now available
Snapshot gcc-10-20221208 is now available on https://gcc.gnu.org/pub/gcc/snapshots/10-20221208/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 10 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-10 revision 76365279b6a76f6c9459409ed71737629db90cb2 You'll find: gcc-10-20221208.tar.xz Complete GCC SHA256=d5a9b3b33376524383bea9abf6dace5857f8ba1106e0b45a1dd25ec08ea27ef2 SHA1=349955d9f980464c4da9aa4df1f94ab16afe6a1d Diffs from 10-20221201 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-10 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Naming flag for specifying the output file name for Binary Module Interface files
It looks like `-fmodule-file` is better from the discussion. So let's take it. Thanks for everyone here~ Thanks, Chuanqi -- From:Nathan Sidwell Send Time:2022年12月8日(星期四) 01:00 To:Iain Sandoe ; GCC Development Cc:Jonathan Wakely ; chuanqi.xcq ; David Blaikie ; ben.boeckel Subject:Re: Naming flag for specifying the output file name for Binary Module Interface files On 12/7/22 11:58, Iain Sandoe wrote: > > >> On 7 Dec 2022, at 16:52, Nathan Sidwell via Gcc wrote: >> >> On 12/7/22 11:18, Iain Sandoe wrote: >> >>> I think it is reasonable to include c++ in the spelling, since other >>> languages supported by >>> GCC (and clang in due course) have modules. >> >> I disagree (about the reasonableness part). Other languages have modules, >> true, but if they want to name the output file, why not have the same option >> spelling? >> >> I.e. why are we considering: >> >> $compiler -fc++-module-file=bob foo.cc >> $compiler -ffortran-module-file=bob foo.f77 >> >> The language is being selected implicitly by the file suffix (or explictly >> via -X$lang). There's no reason for some other option controlling an aspect >> of the compilation to rename the language. We don't do it for >> language-specific warning options, and similar. (i.e. no >> -f[no-]c++-type-aliasing vs -fc-type-aliasing, nor -Wc++-extra vs >> -Wc-extra[*] > > Fair points. > > Unfortunately (in case it has not already been mentioned in this thread) > ‘-fmodule-file=‘ is already taken and it means an input, not an output. So, > whatever we choose it needs to be distinct from that. Yes, that's why I suggested -fmodule-output= nathan -- Nathan Sidwell
