Re: Wrong optimization from ‘fwprop’ pass
Hi! On Wed, Sep 23, 2020 at 10:50:52AM +0800, Jojo R wrote: > insn seqs: > > s1: > > __builtin_set_float_convert_mode(0); > r1 = __builtin_load(a1, a2); > r2 = __builtin_float_convert(r1); > __builtin_store(a3, r2); > __builtin_set_float_convert_mode(0); > > s2: > __builtin_set_float_convert_mode(1); > r1 = __builtin_load(a1, a2); > r2 = __builtin_float_convert(r1); > __builtin_store(a3, r2); > __builtin_set_float_convert_mode(0); > > > the diference of s1 and s2 only is "__builtin_set_float_convert_mode" > > from beginning, the s1 mode is set 0, but s2 mode is set 1. > > From optimization 'fwprop', the s2 insn seqs is deleted > > as dead code with compiler option ‘-O3', is it gcc bug ? > > > builtin patten of __builtin_set_float_convert_mode: > > (define_insn "target_fcvtmode" > [(set (reg:SI FCVTMODE_REGNUM) > (unspec_volatile:SI [(match_operand:SI 0 "operand" "rK")] UNSPECV_FCVTMODE))] > "" > "fcvtmode\t%1" > ) > > > builtin patten of __builtin_set_float_convert_mode: > > (define_insn "target_fcvt" > [(set (match_operand:SI 0 "register_operand" "=r") > (unspec:SI [(match_operand:SF 1 "register_operand" "f")] > UNSPEC_FCVT)) > (use (reg:SI FCVTMODE_REGNUM))] > "" > "fcvt\t%0,%1" > ) That "use" is mostly useless; what you should do afaics is make that FCVTMODE_REGNUM an input of the unspec (and it can just be an unspec, unspec_volatile isn't needed). > As far as i know, __builtin_set_float_convert_mode depend on > 'FCVTMODE_REGNUM' which is from > __builtin_set_float_convert_mode, it's not dead code. The output (operands[0]) does not depend on the convert mode setting, so the second one can be replaced by the first (in CSE or fwprop perhaps), and as end result you get what you observed. Look at what all RTL passes did to your code (-dap is easiest) to see what happened. HtH, Segher
gcc-10-20200926 is now available
Snapshot gcc-10-20200926 is now available on https://gcc.gnu.org/pub/gcc/snapshots/10-20200926/ 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 6f4226ff6e8fa32636153993e2c29e96828bfdb0 You'll find: gcc-10-20200926.tar.xz Complete GCC SHA256=ee83d45f94b8312da89d091bf2a445e4b87e86fbb484aa9c3ae2bfa799d597a1 SHA1=536c1b1c70b6e572d835ea59e29a79c8ce0ee363 Diffs from 10-20200919 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.
The dust seems to have settled from the repository conversion
The dust seems to have settled from the GCC repository conversion. I haven't seen any complaints about the conversion since it was finalized in January, so I'm gathering there have not been any significant problems with it. Unfortunately, it left *me* with a problem. If you're on this list, more than likely you have a full-time job that pays you for working on open-source code. Twenty years ago I sold the business world on the value of open-source shared infrastructure, so you can partly thank me for the fact that you have that option. Ironically, I myself have benefitted very little from that successful persuasion, because the work I do is not closely enough tied to anything a corporation knows it can monetize. Who has a business case for developing something like reposurgeon? I spent most of a year - thousands of hours - focusing on the technical issues associated with the GCC conversion. Because I'm not on salary anywhere, paying bills and not having steady income during that time blew a pretty large hole in my savings account. Now my house needs a new roof, and I have medical bills, and things are looking rather grim. This wasn't the first public infrastructure project I've worked on, and it certainly won't be the last. Reposurgeon, GPSD, NTPsec, giflib - if you have found my work valuable and it gives you confidence that I will continue to do useful things, please subscribe at one of these places: https://www.subscribestar.com/esr https://www.patreon.com/esr Finally, be aware that I am not the only person inn this sort of situation. If you feel motivated to tackle the more general problem of load-bearing Internet people without salaries, please look at http://loadsharers.org take the pledge, and find two load-bearers to support who aren't me. -- http://www.catb.org/~esr/";>Eric S. Raymond
Re: Wrong optimization from ‘fwprop’ pass
Hi, Got it, Thanks :) Jojo 在 2020年9月27日 +0800 AM3:22，Segher Boessenkool ，写道： > Hi! > > On Wed, Sep 23, 2020 at 10:50:52AM +0800, Jojo R wrote: > > insn seqs: > > > > s1: > > > > __builtin_set_float_convert_mode(0); > > r1 = __builtin_load(a1, a2); > > r2 = __builtin_float_convert(r1); > > __builtin_store(a3, r2); > > __builtin_set_float_convert_mode(0); > > > > s2: > > __builtin_set_float_convert_mode(1); > > r1 = __builtin_load(a1, a2); > > r2 = __builtin_float_convert(r1); > > __builtin_store(a3, r2); > > __builtin_set_float_convert_mode(0); > > > > > > the diference of s1 and s2 only is "__builtin_set_float_convert_mode" > > > > from beginning, the s1 mode is set 0, but s2 mode is set 1. > > > > From optimization 'fwprop', the s2 insn seqs is deleted > > > > as dead code with compiler option ‘-O3', is it gcc bug ? > > > > > > builtin patten of __builtin_set_float_convert_mode: > > > > (define_insn "target_fcvtmode" > > [(set (reg:SI FCVTMODE_REGNUM) > > (unspec_volatile:SI [(match_operand:SI 0 "operand" "rK")] > > UNSPECV_FCVTMODE))] > > "" > > "fcvtmode\t%1" > > ) > > > > > > builtin patten of __builtin_set_float_convert_mode: > > > > (define_insn "target_fcvt" > > [(set (match_operand:SI 0 "register_operand" "=r") > > (unspec:SI [(match_operand:SF 1 "register_operand" "f")] > > UNSPEC_FCVT)) > > (use (reg:SI FCVTMODE_REGNUM))] > > "" > > "fcvt\t%0,%1" > > ) > > That "use" is mostly useless; what you should do afaics is make that > FCVTMODE_REGNUM an input of the unspec (and it can just be an unspec, > unspec_volatile isn't needed). > > > As far as i know, __builtin_set_float_convert_mode depend on > > 'FCVTMODE_REGNUM' which is from > > __builtin_set_float_convert_mode, it's not dead code. > > The output (operands[0]) does not depend on the convert mode setting, so > the second one can be replaced by the first (in CSE or fwprop perhaps), > and as end result you get what you observed. Look at what all RTL > passes did to your code (-dap is easiest) to see what happened. > > HtH, > > > Segher
