Re: Detect EAF flags in ipa-modref
On Tue, 10 Nov 2020, Jan Hubicka wrote:
> Hi,
> here is updaed patch.
>
> Honza
>
> Bootstrapped/regtested x86_64-linux, OK (after the fnspec fixes)?
OK.
Thanks,
Richard.
>
> 2020-11-10 Jan Hubicka
>
> * gimple.c: Include ipa-modref-tree.h and ipa-modref.h.
> (gimple_call_arg_flags): Use modref to determine flags.
> * ipa-modref.c: Include gimple-ssa.h, tree-phinodes.h,
> tree-ssa-operands.h, stringpool.h and tree-ssanames.h.
> (analyze_ssa_name_flags): Declare.
> (modref_summary::useful_p): Summary is also useful if arg flags are
> known.
> (dump_eaf_flags): New function.
> (modref_summary::dump): Use it.
> (get_modref_function_summary): Be read for current_function_decl
> being NULL.
> (memory_access_to): New function.
> (deref_flags): New function.
> (call_lhs_flags): New function.
> (analyze_parms): New function.
> (analyze_function): Use it.
> * ipa-modref.h (struct modref_summary): Add arg_flags.
> * doc/invoke.texi (ipa-modref-max-depth): Document.
> * params.opt (ipa-modref-max-depth): New param.
>
> gcc/testsuite/ChangeLog:
>
> 2020-11-10 Jan Hubicka
>
> * gcc.dg/torture/pta-ptrarith-1.c: Escape parametrs.
>
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index d2a188d7c75..0bd76d2841e 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -12953,6 +12953,10 @@ memory locations using the mod/ref information.
> This parameter ought to be
> bigger than @option{--param ipa-modref-max-bases} and @option{--param
> ipa-modref-max-refs}.
>
> +@item ipa-modref-max-depth
> +Specified the maximum depth of DFS walk used by modref escape analysis.
> +Setting to 0 disables the analysis completely.
> +
> @item profile-func-internal-id
> A parameter to control whether to use function internal id in profile
> database lookup. If the value is 0, the compiler uses an id that
> diff --git a/gcc/gimple.c b/gcc/gimple.c
> index 1afed88e1f1..da90716aa23 100644
> --- a/gcc/gimple.c
> +++ b/gcc/gimple.c
> @@ -46,6 +46,8 @@ along with GCC; see the file COPYING3. If not see
> #include "asan.h"
> #include "langhooks.h"
> #include "attr-fnspec.h"
> +#include "ipa-modref-tree.h"
> +#include "ipa-modref.h"
>
>
> /* All the tuples have their operand vector (if present) at the very bottom
> @@ -1532,24 +1534,45 @@ int
> gimple_call_arg_flags (const gcall *stmt, unsigned arg)
> {
>attr_fnspec fnspec = gimple_call_fnspec (stmt);
> -
> - if (!fnspec.known_p ())
> -return 0;
> -
>int flags = 0;
>
> - if (!fnspec.arg_specified_p (arg))
> -;
> - else if (!fnspec.arg_used_p (arg))
> -flags = EAF_UNUSED;
> - else
> + if (fnspec.known_p ())
> {
> - if (fnspec.arg_direct_p (arg))
> - flags |= EAF_DIRECT;
> - if (fnspec.arg_noescape_p (arg))
> - flags |= EAF_NOESCAPE;
> - if (fnspec.arg_readonly_p (arg))
> - flags |= EAF_NOCLOBBER;
> + if (!fnspec.arg_specified_p (arg))
> + ;
> + else if (!fnspec.arg_used_p (arg))
> + flags = EAF_UNUSED;
> + else
> + {
> + if (fnspec.arg_direct_p (arg))
> + flags |= EAF_DIRECT;
> + if (fnspec.arg_noescape_p (arg))
> + flags |= EAF_NOESCAPE;
> + if (fnspec.arg_readonly_p (arg))
> + flags |= EAF_NOCLOBBER;
> + }
> +}
> + tree callee = gimple_call_fndecl (stmt);
> + if (callee)
> +{
> + cgraph_node *node = cgraph_node::get (callee);
> + modref_summary *summary = node ? get_modref_function_summary (node)
> + : NULL;
> +
> + if (summary && summary->arg_flags.length () > arg)
> + {
> + int modref_flags = summary->arg_flags[arg];
> +
> + /* We have possibly optimized out load. Be conservative here. */
> + if (!node->binds_to_current_def_p ())
> + {
> + if ((modref_flags & EAF_UNUSED) && !(flags & EAF_UNUSED))
> + modref_flags &= ~EAF_UNUSED;
> + if ((modref_flags & EAF_DIRECT) && !(flags & EAF_DIRECT))
> + modref_flags &= ~EAF_DIRECT;
> + }
> + flags |= modref_flags;
> + }
> }
>return flags;
> }
> diff --git a/gcc/ipa-modref.c b/gcc/ipa-modref.c
> index 3f46bebed3c..30e76580fb0 100644
> --- a/gcc/ipa-modref.c
> +++ b/gcc/ipa-modref.c
> @@ -61,6 +61,15 @@ along with GCC; see the file COPYING3. If not see
> #include "ipa-fnsummary.h"
> #include "attr-fnspec.h"
> #include "symtab-clones.h"
> +#include "gimple-ssa.h"
> +#include "tree-phinodes.h"
> +#include "tree-ssa-operands.h"
> +#include "ssa-iterators.h"
> +#include "stringpool.h"
> +#include "tree-ssanames.h"
> +
> +static int analyze_ssa_name_flags (tree name,
> +vec &known_flags, int depth);
>
> /* We record fnspec specifiers for call edges since they depends on actual
> gimple statements. */
> @@ -186,6 +195,8 @@ modref_summary::useful_p (int ecf_flags)
Re: gcc/DATESTAMP not updated any longer
On Tue, Nov 10, 2020 at 09:23:09AM +0100, Martin Liška wrote: > On 11/9/20 11:09 PM, Jakub Jelinek wrote: > > So I think either new_update must be raising an exception, or returning > > None for some reason. > > Bet we want to add logging for that exception, as well as for it returning > > None and inside of it perhaps even more detailed logging on where it > > returned None. > > The following should expand both a returned None or an exception. > Jakub, please install it. Just FYI, we have finally the culprit today: 'ascii' codec can't decode byte 0xe2 in position 4882: ordinal not in range(128) Traceback (most recent call last): File "hooks/post_receive.py", line 87, in post_receive File "/sourceware1/projects/src-home/git-hooks/hooks/daemon.py", line 82, in run_in_daemon fun() File "/sourceware1/projects/src-home/git-hooks/hooks/updates/emails.py", line 107, in flush email.send() File "/sourceware1/projects/src-home/git-hooks/hooks/updates/emails.py", line 233, in send e_msg_body = self.__email_body_with_diff File "/sourceware1/projects/src-home/git-hooks/hooks/updates/emails.py", line 310, in __email_body_with_diff email_body += diff UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 4882: ordinal not in range(128) and at least in a couple of past missed mails it is the git diff containing non-ascii characters (usually valid utf-8, but I think we even shouldn't throw away mails that contain something not valid utf-8). Jakub
Re: CSE deletes valid REG_EQUAL?
Hi guys, On Thu, Nov 12, 2020 at 09:10:14PM -0700, Jeff Law wrote: > On 11/12/20 7:02 PM, Xionghu Luo via Gcc wrote: > > The output shows "REQ_EQUAL r118:DI+0x66546b64" is deleted by > > df_remove_dead_eq_notes, > > but r120:DI is not REG_DEAD here, so is it correct here to check insn use > > and find that > > r118:DI is dead then do the delete? > > It doesn't matter where the death occurs, any REG_DEAD note will cause > the REG_EQUAL note to be removed. So given the death note for r118, > then any REG_EQUAL note that references r118 will be removed. This is > overly pessimistic as the note may still be valid/useful at some > points. See > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92291 The note even *always* is valid where it is! As you say, the REG_EQUAL is only (necessarily) valid at *that* insn. And this insn *sets* the reg (that is the only case when a REG_EQ* is allowed at all), so if the eq reg is dead (i.e. unused) the whole insn is, and the insn can be removed. Removing all REG_EQUAL notes for regs that become dead anywhere seems to just be a thinko? All pseudos are dead somewhere! (Yeah okay, infinite loops, but other than that.) Segher
Re: Split DWARF and rnglists, gcc vs clang
On 2020-11-12 7:11 p.m., Mark Wielaard wrote: > Hi Simon, > > On Thu, Nov 05, 2020 at 11:11:43PM -0500, Simon Marchi wrote: >> I'm currently squashing some bugs related to .debug_rnglists in GDB, and >> I happened to notice that clang and gcc do different things when >> generating rnglists with split DWARF. I'd like to know if the two >> behaviors are acceptable, and therefore if we need to make GDB accept >> both. Or maybe one of them is not doing things correctly and would need >> to be fixed. >> >> clang generates a .debug_rnglists.dwo section in the .dwo file. Any >> DW_FORM_rnglistx attribute in the DWO refers to that section. That >> section is not shared with any other object, so DW_AT_rnglists_base is >> never involved for these attributes. Note that there might still be a >> DW_AT_rnglists_base on the DW_TAG_skeleton_unit, in the linked file, >> used if the skeleton itself has an attribute of form DW_FORM_rnglistx. >> This rnglist would be found in a .debug_rnglists section in the linked >> file, shared with the other units of the linked file. >> >> gcc generates a single .debug_rnglists in the linked file and no >> .debug_rnglists.dwo in the DWO files. So when an attribute has form >> DW_FORM_rnglistx in a DWO file, I presume we need to do the lookup in >> the .debug_rnglists section in the linked file, using the >> DW_AT_rnglists_base attribute found in the corresponding skeleton unit. >> This looks vaguely similar to how it was done pre-DWARF 5, with >> DW_AT_GNU_ranges base. >> >> So, is gcc wrong here? I don't see anything in the DWARF 5 spec >> prohibiting to do it like gcc does, but clang's way of doing it sounds >> more in-line with the intent of what's described in the DWARF 5 spec. >> So I wonder if it's maybe an oversight or a misunderstanding between the >> two compilers. > > I think I would have asked the question the other way around :) The > spec explicitly describes rnglists_base (and loclists_base) as a way > to reference ranges (loclists) through the index table, so that the > only relocation you need is in the (skeleton) DIE. I presume you reference this non-normative text in section 2.17.3? This range list representation, the rnglist class, and the related DW_AT_rnglists_base attribute are new in DWARF Version 5. Together they eliminate most or all of the object language relocations previously needed for range lists. What I understand from this is that the rnglist class and DW_AT_rnglists_base attribute help reduce the number of relocations in the non-split case (it removes the need for relocations from DW_AT_ranges attribute values in .debug_info to .debug_rnglists). I don't understand it as saying anything about where to put the rnglist data in the split-unit case. > But the rnglists > (loclists) themselves can still use relocations. A large part of them > is non-shared addresses, so using indexes (into the .debug_addr > addr_base) would simply be extra overhead. The relocations will > disappear once linked, but the index tables won't. > > As an alternative, if you like to minimize the amount of debug data in > the main object file, the spec also describes how to put a whole > .debug_rnglists.dwo (or .debug_loclists.dwo) in the split dwarf > file. Then you cannot use all entry encodings and do need to use an > .debug_addr index to refer to any addresses in that case. So the > relocations are still there, you just refer to them through an extra > index indirection. > > So I believe both encodings are valid according to the spec. It just > depends on what you are optimizing for, small main object file size or > smallest encoding with least number of indirections. So, if I understand correctly, gcc's way of doing things (putting all the rnglists in a common .debug_rnglists section) reduces the overall size of debug info since the rnglists can use the direct addressing rnglists entries (e.g. DW_RLE_start_end) rather than the indirect ones (e.g. DW_RLE_startx_endx). But this come at the expense of a lot of relocations in the rnglists themselves, since they refer to addresses directly. I thought that the main point of split-units was to reduce the number of relocations processed by the linker and data moved around by the linker, to reduce link time and provide a better edit-build-debug cycle. Is that the case? Anyway, regardless of the intent, the spec should ideally be clear about that so we don't have to guess. > P.S. I am really interested in these interpretations of DWARF, but I > don't really follow the gdb implementation details very much. Could we > maybe move discussions like these from the -patches list to the main > gdb (or gcc) mailinglist? Sure, I added gdb@ and gcc@. I also left gdb-patches@ so that it's possible to follow the discussion there. Simon
Sensors Expo & Conference Visitors Info List
Hello Hope you and your family are safe !! Myself Zoe Wilde, Business Analyst of Inside data view. We would like to follow-up with you for the below mentioned exhibition attendees' s database. Expo details Sensors Expo & Conference 16 - 18 Nov 2020 San Jose Convention Center, San Jose, USA Count=4226 Data base contains: * Contact Name * Email Address * Phone No * Title, Company Name * URL/Website * City * Country We await your interest to obtain the above-mentioned database. Please feel free to write us and we can come up with an attractive price for you. Kindly let us know your thoughts, so we can send you more information on same. Best Regards, Zoe Wilde Business Analyst
Re: Split DWARF and rnglists, gcc vs clang
Hi Simon, On Fri, 2020-11-13 at 09:45 -0500, Simon Marchi wrote: > I think I would have asked the question the other way around :) The > > spec explicitly describes rnglists_base (and loclists_base) as a way > > to reference ranges (loclists) through the index table, so that the > > only relocation you need is in the (skeleton) DIE. > > I presume you reference this non-normative text in section 2.17.3? > > This range list representation, the rnglist class, and the related > DW_AT_rnglists_base attribute are new in DWARF Version 5. Together > they eliminate most or all of the object language relocations > previously needed for range lists. That too, but I was actually referring to the sections that define Range List and Location List Tables (7.28 and 7.29) which define the meaning of DW_AT_rnglists_base and DW_AT_loclists_base. But you could also look at 3.1.3 Split Full Compilation Unit Entries which says that those base attributes are inherited from the corresponding skeleton compilation unit for a split unit. > What I understand from this is that the rnglist class and > DW_AT_rnglists_base attribute help reduce the number of relocations in > the non-split case (it removes the need for relocations from > DW_AT_ranges attribute values in .debug_info to .debug_rnglists). I > don't understand it as saying anything about where to put the rnglist > data in the split-unit case. I interpreted it as when there is a base attribute in the (skeleton) unit, then the corresponding section (index table) can be found in the main object file. At least that is how elfutils libdw interprets the base attributes, not just for rnglists_base, but also str_offsets_base, addr_base, etc. And that is also how/when GCC emits them. > > So I believe both encodings are valid according to the spec. It just > > depends on what you are optimizing for, small main object file size or > > smallest encoding with least number of indirections. > > So, if I understand correctly, gcc's way of doing things (putting all > the rnglists in a common .debug_rnglists section) reduces the overall > size of debug info since the rnglists can use the direct addressing > rnglists entries (e.g. DW_RLE_start_end) rather than the indirect ones > (e.g. DW_RLE_startx_endx). But this come at the expense of a lot of > relocations in the rnglists themselves, since they refer to addresses > directly. Yes, and it reduces the number of .debug_addr entries that need relocations. > I thought that the main point of split-units was to reduce the number of > relocations processed by the linker and data moved around by the linker, > to reduce link time and provide a better edit-build-debug cycle. Is > that the case? I think it depends on who exactly you ask and what their specific goals/setups are. Both things, reducing the number of relocations and moving data out of the main object file, are independently useful in different context. But I think it is mainly reducing the number of relocations that is beneficial. For example clang (but not yet gcc) supports having the .dwo sections themselves in the main object file (using SHF_EXCLUDED for the .dwo sections, so the linker will still skip them). Which is also a possibility that the spec describes and which really makes split DWARF much more usable, because then you don't need to change your build system to deal with multiple output files. > > P.S. I am really interested in these interpretations of DWARF, but I > > don't really follow the gdb implementation details very much. Could we > > maybe move discussions like these from the -patches list to the main > > gdb (or gcc) mailinglist? > > Sure, I added gdb@ and gcc@. I also left gdb-patches@ so that it's > possible to follow the discussion there. Thanks, Mark
Re: Split DWARF and rnglists, gcc vs clang
On 2020-11-13 10:18 a.m., Mark Wielaard wrote: > That too, but I was actually referring to the sections that define > Range List and Location List Tables (7.28 and 7.29) which define the > meaning of DW_AT_rnglists_base and DW_AT_loclists_base. But you could > also look at 3.1.3 Split Full Compilation Unit Entries which says that > those base attributes are inherited from the corresponding skeleton > compilation unit for a split unit. Hmm, indeed, if we interpret that sentence in 3.1.3 to the letter, it suggests that the the DW_FORM_rnglistx attributes in the DWO are meant to point in the linked file's .debug_rnglists. Otherwise, inheriting DW_AT_rnglists_base wouldn't be meaningful. But when DWO files use a .debug_rnglists.dwo section, it doesn't make sense to consider the inherited DW_AT_rnglists_base. So in the end the logical thing to do when encountering a DW_FORM_rnglistx in a split-unit, in order to support everybody, is probably to go to the .debug_rnglists.dwo section, if there's one, disregarding the (inherited) DW_AT_rnglists_base. If there isn't, then try the linked file's .debug_rnglists section, using DW_AT_rnglists_base. If there isn't, then something is malformed. >> What I understand from this is that the rnglist class and >> DW_AT_rnglists_base attribute help reduce the number of relocations in >> the non-split case (it removes the need for relocations from >> DW_AT_ranges attribute values in .debug_info to .debug_rnglists). I >> don't understand it as saying anything about where to put the rnglist >> data in the split-unit case. > > I interpreted it as when there is a base attribute in the (skeleton) > unit, then the corresponding section (index table) can be found in the > main object file. That doesn't work with how clang produces it, AFAIU. There is a DW_AT_rnglists_base attribute in the skeleton and a .debug_rnglists in the linked file, which is used for the skeleton's DW_AT_ranges attribute. And there is also .debug_rnglists.dwo sections in the DWO files. So DW_FORM_rnglistx values in the skeleton use the .debug_rnglists in the linked file, while the DW_FORM_rnglistx values in the DWO file use the .debug_rnglists.dwo in that file (even though there is a DW_AT_rnglists_base in the skeleton). > At least that is how elfutils libdw interprets the > base attributes, not just for rnglists_base, but also str_offsets_base, > addr_base, etc. And that is also how/when GCC emits them. > >>> So I believe both encodings are valid according to the spec. It just >>> depends on what you are optimizing for, small main object file size or >>> smallest encoding with least number of indirections. >> >> So, if I understand correctly, gcc's way of doing things (putting all >> the rnglists in a common .debug_rnglists section) reduces the overall >> size of debug info since the rnglists can use the direct addressing >> rnglists entries (e.g. DW_RLE_start_end) rather than the indirect ones >> (e.g. DW_RLE_startx_endx). But this come at the expense of a lot of >> relocations in the rnglists themselves, since they refer to addresses >> directly. > > Yes, and it reduces the number of .debug_addr entries that need > relocations. > >> I thought that the main point of split-units was to reduce the number of >> relocations processed by the linker and data moved around by the linker, >> to reduce link time and provide a better edit-build-debug cycle. Is >> that the case? > > I think it depends on who exactly you ask and what their specific > goals/setups are. Both things, reducing the number of relocations and > moving data out of the main object file, are independently useful in > different context. But I think it is mainly reducing the number of > relocations that is beneficial. For example clang (but not yet gcc) > supports having the .dwo sections themselves in the main object file > (using SHF_EXCLUDED for the .dwo sections, so the linker will still > skip them). Which is also a possibility that the spec describes and > which really makes split DWARF much more usable, because then you don't > need to change your build system to deal with multiple output files. Not sure I understand. Does that mean that the .dwo sections are emitted in the .o files, and that's the end of the road for them? The DW_AT_dwo_name attributes of the skeletons then refer to the .o files? Simon
Re: Split DWARF and rnglists, gcc vs clang
Hi Simon, On Fri, 2020-11-13 at 10:41 -0500, Simon Marchi wrote: > So in the end the logical thing to do when encountering a > DW_FORM_rnglistx in a split-unit, in order to support everybody, is > probably to go to the .debug_rnglists.dwo section, if there's one, > disregarding the (inherited) DW_AT_rnglists_base. If there isn't, then > try the linked file's .debug_rnglists section, using > DW_AT_rnglists_base. If there isn't, then something is malformed. Yes, I think that makes sense. > > I interpreted it as when there is a base attribute in the (skeleton) > > unit, then the corresponding section (index table) can be found in the > > main object file. > > That doesn't work with how clang produces it, AFAIU. There is a > DW_AT_rnglists_base attribute in the skeleton and a .debug_rnglists in > the linked file, which is used for the skeleton's DW_AT_ranges > attribute. And there is also .debug_rnglists.dwo sections in the DWO > files. So DW_FORM_rnglistx values in the skeleton use the > .debug_rnglists in the linked file, while the DW_FORM_rnglistx values > in the DWO file use the .debug_rnglists.dwo in that file (even though > there is a DW_AT_rnglists_base in the skeleton). I would have expected the skeleton's DW_AT_ranges to use DW_FORM_secoffset, not DW_FORM_rnglistx. Precisely because you would then get an ambiguity. But it would indeed be good to handle that situation. > > I think it depends on who exactly you ask and what their specific > > goals/setups are. Both things, reducing the number of relocations and > > moving data out of the main object file, are independently useful in > > different context. But I think it is mainly reducing the number of > > relocations that is beneficial. For example clang (but not yet gcc) > > supports having the .dwo sections themselves in the main object file > > (using SHF_EXCLUDED for the .dwo sections, so the linker will still > > skip them). Which is also a possibility that the spec describes and > > which really makes split DWARF much more usable, because then you don't > > need to change your build system to deal with multiple output files. > > Not sure I understand. Does that mean that the .dwo sections are > emitted in the .o files, and that's the end of the road for them? The > DW_AT_dwo_name attributes of the skeletons then refer to the .o files? Yes, precisely. I am not sure whether it is already in any released clang, but if it is you could try -gsplit-dwarf=single to see an example. Note that elfutils libdw doesn't yet handle that variant. Luckily not because of a design issue, but because there are some sanity checks that trigger when seeing a .debug_xxx and .debug_xxx.dwo section in the same file. I have a partial patch to fix that and make it so that you can explicitly open a file as either a "main" Dwarf or "split" Dwarf. The only thing it doesn't do yet is share the file handle between the Dwarf object (which isn't strictly needed, but would be a nice optimization). I actually think having a "single" split-dwarf file (.o == .dwo) is the best way to support Split Dwarf more generically because then it would simply work without having to adjust all build systems to work with/around separate .dwo files. Cheers, Mark
gcc-9-20201113 is now available
Snapshot gcc-9-20201113 is now available on https://gcc.gnu.org/pub/gcc/snapshots/9-20201113/ 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 62c2d527307d8adce31f5c9ca6e19e15b2866b83 You'll find: gcc-9-20201113.tar.xzComplete GCC SHA256=84376ef0ee749441eaf7821c7cd0b6622b3594114ab8028bc57ff96fa721b9ad SHA1=63048c06b7d2c9f691faf400abb665848903fc5f Diffs from 9-20201106 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.
