Tune cunroll/cunrolli through params
Hi, I'm thinking about to tune the cunroll and cunrolli. And I also had some tests about parameters like: param_max_completely_peel_times, param_max_peel_times, param_max_completely_peeled_insns... During tunning those parameters, I find there are some cases that are improved, while there are always some other benchmarks downgrade. For example: max-completely-peel-times=8 helps 523.xalancbmk_r, but downgrade happens on 511.povray_r with this paramter on some machines. max-completely-peel-times=10 helps 511.povray_r, but downgrade happens on 503.bwaves_r. Below are those parameters which already exist to tune cunroll/cunrolli. param_max_completely_peel_times 16(default). param_max_completely_peeled_insns 200 param_max_peel_branches 32 param_max_peel_times 16 param_max_peeled_insns 100 param_max_unroll_iterations 8 Do you have any suggestions about tuning the parameters? Thanks! Jiufu Guo
Re: Tune cunroll/cunrolli through params
On 10/9/20 10:06 AM, Jiufu Guo wrote: Hi, I'm thinking about to tune the cunroll and cunrolli. And I also had some tests about parameters like: param_max_completely_peel_times, param_max_peel_times, param_max_completely_peeled_insns... During tunning those parameters, I find there are some cases that are improved, while there are always some other benchmarks downgrade. For example: max-completely-peel-times=8 helps 523.xalancbmk_r, but downgrade happens on 511.povray_r with this paramter on some machines. max-completely-peel-times=10 helps 511.povray_r, but downgrade happens on 503.bwaves_r. Below are those parameters which already exist to tune cunroll/cunrolli. param_max_completely_peel_times 16(default). param_max_completely_peeled_insns 200 param_max_peel_branches 32 param_max_peel_times 16 param_max_peeled_insns 100 param_max_unroll_iterations 8 Do you have any suggestions about tuning the parameters? Thanks! Jiufu Guo Adding Honza's proper email address. He may have some opinion about the params. Martin
support in C++2x
Hi being deprecated for nearly 20 years of C++ standards has always been a bit baffling to me. I'm used to thingis being deprecated and then removed a bit faster than that. It is still deprecated in C++17 but does not appear in C++2x as of draft N4860. GCC 10 still behaves the same and you get a deprecated warning when you use --std=c++2x. Am I reading the draft N4860 correctly and it is finally being removed? The warning is generic for using it and it seems as though more direct guidance could be given if it has been removed. /home/joel/rtems-work/tools/6/lib/gcc/i386-rtems6/10.2.1/include/c++/backward/backward_warning.h:32:2: warning: #warning This file includes at least one deprecated or antiquated header which may be removed without further notice at a future date. Please use a non-deprecated interface with equivalent functionality instead. For a listing of replacement headers and interfaces, consult the file backward_warning.h. To disable this warning use -Wno-deprecated. [-Wcpp] I'm far from complaining about it being removed. I just want to make sure I am interpreting the draft C++ standard correctly and see if there is a desired to slightly improve GCC's warning to give more specific advice. Thanks. --joel RTEMS
Re: support in C++2x
On Fri, 9 Oct 2020 at 14:31, Joel Sherrill wrote: > > Hi > > being deprecated for nearly 20 years of C++ standards has > always been a bit baffling to me. I'm used to thingis being deprecated and > then removed a bit faster than that. > > It is still deprecated in C++17 but does not appear in C++2x as of > draft N4860. GCC 10 still behaves the same and you get a deprecated warning > when you use --std=c++2x. > > Am I reading the draft N4860 correctly and it is finally being removed? No, it's still there in the same place, Annex D. See D.12 [depr.strstreambuf]. > The warning is generic for using it and it seems as though more direct > guidance could be given if it has been removed. It hasn't been. It won't be removed until a suitable replacement is added to the library, and even then implementations won't be required to remove it. We still make std::auto_ptr available despite it being removed in C++17 (after deprecation in C++11). > /home/joel/rtems-work/tools/6/lib/gcc/i386-rtems6/10.2.1/include/c++/backward/backward_warning.h:32:2: > warning: #warning This file includes at least one deprecated or antiquated > header which may be removed without further notice at a future date. Please > use a non-deprecated interface with equivalent functionality instead. For a > listing of replacement headers and interfaces, consult the file > backward_warning.h. To disable this warning use -Wno-deprecated. [-Wcpp] > > I'm far from complaining about it being removed. I just want to make sure I > am interpreting the draft C++ standard correctly and see if there is a > desired to slightly improve GCC's warning to give more specific advice. The libstdc++ list would be a better place to discuss that kind of thing.
Re: support in C++2x
On Fri, Oct 9, 2020 at 8:49 AM Jonathan Wakely wrote: > On Fri, 9 Oct 2020 at 14:31, Joel Sherrill wrote: > > > > Hi > > > > being deprecated for nearly 20 years of C++ standards has > > always been a bit baffling to me. I'm used to thingis being deprecated > and > > then removed a bit faster than that. > > > > It is still deprecated in C++17 but does not appear in C++2x as of > > draft N4860. GCC 10 still behaves the same and you get a deprecated > warning > > when you use --std=c++2x. > > > > Am I reading the draft N4860 correctly and it is finally being removed? > > No, it's still there in the same place, Annex D. See D.12 > [depr.strstreambuf]. > Apparently the PDF file is huge and was taking forever to load and that's why my search for "strstr" didn't turn up anything. I'm asking because this came up in a discussion of whether the FACE Technical Standard for avionics should consider forbidding its use as deprecated. It sounds like we are years away from it disappearing and avionics applications do not use the latest C++ versions anyway. In your opinion, would using this be a risk for use in a long-lived application? > > The warning is generic for using it and it seems as though more direct > > guidance could be given if it has been removed. > > It hasn't been. It won't be removed until a suitable replacement is > added to the library, and even then implementations won't be required > to remove it. We still make std::auto_ptr available despite it being > removed in C++17 (after deprecation in C++11). > It is a hard edge to walk when you have to obsolete something. Over at RTEMS, we have had a great port of FreeBSD services including IPV4, IPV6, Wifi, USB, SDMMC, etc. for at least five years. But getting rid of the 20+ year old IPV4 only FreeBSD stack is going to be a pain for users who will have to port drivers to the new stack. Killing old features isn't easy. We all want to minimize impact on users. > > > /home/joel/rtems-work/tools/6/lib/gcc/i386-rtems6/10.2.1/include/c++/backward/backward_warning.h:32:2: > > warning: #warning This file includes at least one deprecated or > antiquated > > header which may be removed without further notice at a future date. > Please > > use a non-deprecated interface with equivalent functionality instead. > For a > > listing of replacement headers and interfaces, consult the file > > backward_warning.h. To disable this warning use -Wno-deprecated. [-Wcpp] > > > > I'm far from complaining about it being removed. I just want to make > sure I > > am interpreting the draft C++ standard correctly and see if there is a > > desired to slightly improve GCC's warning to give more specific advice. > > The libstdc++ list would be a better place to discuss that kind of thing. > If it hasn't been removed, then this is more than acceptable. If it is ever is removed, then a more precise message may be useful. Thank you for the quick response. --joel
Re: support in C++2x
On Fri, 9 Oct 2020 at 15:13, Joel Sherrill wrote: > > > > On Fri, Oct 9, 2020 at 8:49 AM Jonathan Wakely wrote: >> >> On Fri, 9 Oct 2020 at 14:31, Joel Sherrill wrote: >> > >> > Hi >> > >> > being deprecated for nearly 20 years of C++ standards has >> > always been a bit baffling to me. I'm used to thingis being deprecated and >> > then removed a bit faster than that. >> > >> > It is still deprecated in C++17 but does not appear in C++2x as of >> > draft N4860. GCC 10 still behaves the same and you get a deprecated warning >> > when you use --std=c++2x. >> > >> > Am I reading the draft N4860 correctly and it is finally being removed? >> >> No, it's still there in the same place, Annex D. See D.12 >> [depr.strstreambuf]. > > > Apparently the PDF file is huge and was taking forever to load and that's > why my search for "strstr" didn't turn up anything. > > I'm asking because this came up in a discussion of whether the FACE > Technical Standard for avionics should consider forbidding its use > as deprecated. It sounds like we are years away from it disappearing > and avionics applications do not use the latest C++ versions anyway. > > In your opinion, would using this be a risk for use in a long-lived > application? std::ostrstream should never be used anyway IMHO. It's too hard to use correctly. std::istrstream is safe, but might finally be on its way out if http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0448r2.pdf makes progress for C++23. Or maybe istrstream should be undeprecated (maybe after removing ostrstream). http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2139r0.html#3.12 touches on what should happen to them.
Question about interpreting a decl dump
Hi, I am currently trying to get the argument lists for calling intrinsic functions right, and I have run across something in a tree I do not understand. The declaration is: unit-size align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7feefcfec5e8 precision:32 min 0x7feefcfd7db0 -2147483648> max pointer_to_this > QI size unit-size align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7feefce49540 attributes value >> arg-types 0x7feefce491f8> chain 0x7feefce493f0> chain 0x7feefcff9000 logical(kind=4)> chain 0x7feefcfec738 integer(kind=8)> chain > and the library function has mmaxloc2_4_s1 (gfc_array_s1 * const restrict array, gfc_array_l1 * const restrict mask, GFC_LOGICAL_4 back, gfc_charlen_type len) As far as I can tell, the decl looks correct, but I am a bit confused by the final chain > there. Should that be there? What does it mean? Best regards Thomas
Re: Question about interpreting a decl dump
Thomas Koenig via Fortran wrote: and the library function has mmaxloc2_4_s1 (gfc_array_s1 * const restrict array, gfc_array_l1 * const restrict mask, GFC_LOGICAL_4 back, gfc_charlen_type len) As far as I can tell, the decl looks correct, but I am a bit confused by the final chain > there. Should that be there? What does it mean? FUNCTION_TYPE If the last node in the list is void_list_node (a TREE_LIST node whose TREE_VALUE is the void_type_ node), then functions of this type do not take variable arguments. Otherwise, they do take a variable number of arguments. HTH Iain
Re: Question about interpreting a decl dump
Hi Iain, If the last node in the list is void_list_node (a TREE_LIST node whose TREE_VALUE is the void_type_ node), then functions of this type do not take variable arguments. Otherwise, they do take a variable number of arguments. > HTH That does help, a lot. It means that this decl is correct, and many others are not. I'll do some more digging to see where the void_list_node should have been appended. Thanks! Thomas
gcc-9-20201009 is now available
Snapshot gcc-9-20201009 is now available on https://gcc.gnu.org/pub/gcc/snapshots/9-20201009/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 9 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-9 revision f3327324f9f533c1798485b4789137893e2efd1b You'll find: gcc-9-20201009.tar.xzComplete GCC SHA256=2b64eece18ff312aca0f359e52caec5b9dcb7fa14a13e045e601be51b13bba61 SHA1=943cec33eba4b5d81f3617220f50031a90bafaac Diffs from 9-20201002 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-9 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.
How to check reachable between blocks
Hi, Is there any API or common codes to check any two blocks is reachable ? Thanks. Jojo
Re: How to check reachable between blocks
On Fri, Oct 9, 2020 at 8:01 PM Jojo R wrote: > > Hi, > > Is there any API or common codes to check any two blocks is reachable > ? Yes the API in dominance.h. Depending on where you use it, you might need to have it created. Using calculate_dominance_info function. The function to do the check is dominated_by_p. Thanks, Andrew Pinski > > Thanks. > > Jojo
Re: How to check reachable between blocks
Hi, Thanks, i will dig it deeply :) Jojo 在 2020年10月10日 +0800 AM11:14，Andrew Pinski ，写道： > On Fri, Oct 9, 2020 at 8:01 PM Jojo R wrote: > > > > Hi, > > > > Is there any API or common codes to check any two blocks is reachable ? > > Yes the API in dominance.h. > Depending on where you use it, you might need to have it created. > Using calculate_dominance_info function. > The function to do the check is dominated_by_p. > > Thanks, > Andrew Pinski > > > > > > Thanks. > > > > Jojo
