Re: Questions regarding control flow during IPA passes
On Fri, Jul 3, 2020 at 6:04 AM Gary Oblock via Gcc wrote: > > At IPA time I'm creating GIMPLE statements. I've noticed during dumps > that gotos and labels don't seem to exist. In fact when I tried > introducing them, at least the gotos, failed. I assume that at this > point in compilation GCC relies on the control flow graph (which I'm > updating as I create new BBs) so I actually shouldn't create them? > Furthermore, I assume I should be setting the "gotos" in the condition > statement to NULL? Yes and Yes. > Thanks, > > Gary Oblock > Ampere Computing > Santa Clara, California > > > CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is > for the sole use of the intended recipient(s) and contains information that > is confidential and proprietary to Ampere Computing or its subsidiaries. It > is to be used solely for the purpose of furthering the parties' business > relationship. Any review, copying, or distribution of this email (or any > attachments thereto) is strictly prohibited. If you are not the intended > recipient, please contact the sender immediately and permanently delete the > original and any copies of this email and any attachments thereto.
Re: An problematic interaction between a call created by gimple_build_call and inlining
Hi, On Thu, Jul 02 2020, Gary Oblock wrote: > Martin, > > What about immediate dominators? I'm afraid I don't understand your question, what about them? Dominators are re-computed after inlining and after clones are materialized (when they get their own body)... I believe. We do not store information which call graph edges dominate other call graph edges in the callers body. Having that information might be useful at IPA stage. But yeah, please be more specific what your question is. Martin > > > From: Martin Jambor > Sent: Wednesday, July 1, 2020 3:40 PM > To: Gary Oblock ; Richard Biener > > Cc: gcc@gcc.gnu.org > Subject: Re: An problematic interaction between a call created by > gimple_build_call and inlining > > [EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please > be mindful of safe email handling and proprietary information protection > practices.] > > > Hi, > > On Wed, Jul 01 2020, Gary Oblock via Gcc wrote: >> Thank you Richard. >> >> I feel a bit dumb because I'm well aware of the GCC philosophy to have >> any new code produced update the state. Of course I didn't know the >> commands to do this for the call graph (which I really appreciate you >> giving.) >> >> However, the real reason I'm sending a reply is this. Are there any >> surprising >> cases in IPA where GCC violates its philosophy and actually regenerates the >> information? > > if by "the information" you specifically mean call graph edges then no. > (Regular) IPA optimizations are designed to also work when doing link > time optimization (LTO) which means that unless they specifically load > the (gimple) bodies of some selected functions, the bodies are not > available to them. They only operate on the call graph and information > they collected when generating summaries. Because gimple body is not > available, call graph edges cannot be regenerated from it. > > In fact, when a call is redirected to a different/specialized function, > at IPA time it is only recored in the call graph by redirecting the > corresponding edge and the call statement is modified only at the end of > IPA phase (in LTRANS in LTO-speak). This is necessary even when not > using LTO because until specialized nodes get their own body, they share > it with the node from which they were cloned. That means that several > call graph edges, which do not share caller and may not even share the > callee, refer to the same gimple statement - so the decl in the > statement is actually meaningless and the edge encodes the important > information. > > Martin
Re: [OMPD] Questions on per-process functions and related data types.
On Thu, Jul 02, 2020 at 06:58:49PM -0400, y2s1982 . via Gcc wrote: > This is giving me more clarity on what I have to do. At the moment, I am > storing the > information in the handle. > > I do have one problem: in 5.5.2.1 ( > https://www.openmp.org/spec-html/5.0/openmpsu214.html#x270-18090005.5.2) > it states that the call may verify the version compatibility using the > context. > How should I handle this? It is up to the implementation to decide what can it handle and what it can't, the OMPD will be evolving, new callbacks will be added, old ones deprecated etc. As initially there will be just a single version supported (the 5.0 one), until 5.1 is implemented we should just reject any incompatible versions, and only when we implement 5.1 decide if we can accept 5.0 requests. Jakub
Re: [OMPD] Questions on per-process functions and related data types.
Hello, On Fri, Jul 3, 2020 at 10:06 AM Jakub Jelinek wrote: > On Thu, Jul 02, 2020 at 06:58:49PM -0400, y2s1982 . via Gcc wrote: > > This is giving me more clarity on what I have to do. At the moment, I am > > storing the > > information in the handle. > > > > I do have one problem: in 5.5.2.1 ( > > https://www.openmp.org/spec-html/5.0/openmpsu214.html#x270-18090005.5.2) > > it states that the call may verify the version compatibility using the > > context. > > How should I handle this? > > It is up to the implementation to decide what can it handle and what it > can't, the OMPD will be evolving, new callbacks will be added, old ones > deprecated etc. > As initially there will be just a single version supported (the 5.0 one), > until 5.1 is implemented we should just reject any incompatible versions, > and only when we implement 5.1 decide if we can accept 5.0 requests. > Thank you for the clarity on this. The task seems simple for now with respect to version compatibility. Still, following the documentation 5.5.2.1, how should I extract version information from ompd_address_space_context_t that is owned by the debugger instead of the OMPD to check for compatibility , especially when it is not currently defined? Should I leave that portion for later? Cheers, Tony Sim > > Jakub > >
Re: [OMPD] Questions on per-process functions and related data types.
On Fri, Jul 03, 2020 at 10:26:27AM -0400, y2s1982 . wrote: > Still, following the documentation 5.5.2.1, how should I extract version > information from ompd_address_space_context_t that is owned by the > debugger instead of the OMPD to check for compatibility , especially > when it is not currently defined? For ompd_process_initialize, you can use the callbacks to find out anything you want. In particular, e.g. ompd_callback_symbol_addr_fn_t callback can be used to look up some magic symbol that you'd add to libgomp.so.1 (GOMP_library_details or whatever else), which would be some (ideally read-only) data variable that will describe everything OMPD needs to know about the library; if that symbol isn't found, you'd say it is incompatible, if it is found, you'd read it and parse it. It would be nice if the variable contains data in some extensible format, which would allow for compatible (one version of libgompd.so.1 handling older or newer libgomp.so.1) or incompatible (something OMPD will not be able to deal with) changes and encode everything you'll need to know (offsets into internal structures where needed, their sizes, etc.) in some compact form. You can use the ompd_callback_memory_read_fn_t callback to read data from that variable. Jakub
Re: [OMPD] Questions on per-process functions and related data types.
Hello Jakub, On Fri, Jul 3, 2020 at 10:40 AM Jakub Jelinek wrote: > On Fri, Jul 03, 2020 at 10:26:27AM -0400, y2s1982 . wrote: > > Still, following the documentation 5.5.2.1, how should I extract version > > information from ompd_address_space_context_t that is owned by the > > debugger instead of the OMPD to check for compatibility , especially > > when it is not currently defined? > > For ompd_process_initialize, you can use the callbacks to find out anything > you want. > In particular, e.g. ompd_callback_symbol_addr_fn_t callback can be used to > look up some magic symbol that you'd add to libgomp.so.1 > (GOMP_library_details or whatever else), which would be some (ideally > read-only) data variable that will describe everything OMPD needs to know > about the library; if that symbol isn't found, you'd say it is > incompatible, > if it is found, you'd read it and parse it. > Thank you for clarifying how ompd_callback_symbol_addr_fn_t callback can used. Are there any existing symbols I can lookup using this function and the current libgomp.so.1, such as information on cuda device id? > It would be nice if the variable contains data in some extensible format, > which would allow for compatible (one version of libgompd.so.1 handling > older or newer libgomp.so.1) or incompatible (something OMPD will not be > able to deal with) changes and encode everything you'll need to know > (offsets into internal structures where needed, their sizes, etc.) in some > compact form. You can use the ompd_callback_memory_read_fn_t callback > to read data from that variable. What kind of information should I put in? At the moment, I am thinking of creating a packet with following memory structure: a header portion of one byte that represents the total byte size of the encoded packet, followed by a series of bits, each representing compatibility of a particular OMPD version. I would then use an enum with specific numerical values representing each OMPD version to bitshift or otherwise represent the version. Is this a correct direction of thought? > > Jakub > >
gcc-9-20200703 is now available
Snapshot gcc-9-20200703 is now available on https://gcc.gnu.org/pub/gcc/snapshots/9-20200703/ 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 709faac49c7260c2e40da0a7727630ef6c72b59a You'll find: gcc-9-20200703.tar.xzComplete GCC SHA256=8ff33ecd506f7e0ca5bead24c5deed706705e7c03871b015b11bb38dbcefbfd4 SHA1=6e935cbb2c17d35fee0e0a39f2f53fe128aa66eb Diffs from 9-20200626 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.
Re: An problematic interaction between a call created by gimple_build_call and inlining
Martin, Actually it's basic blocks that dominate on another though I suppose you could generalize the notion to CFG edges but to what point? I'm seeing in some of the code that I read, immediate dominators being manually computed and added to the BBs at their point of creation. At the moment I'm punting on creating them hoping I don't create an untenable state which results in hard to diagnose failures. I was just trying to avoid this. Thanks, Gary Oblock From: Martin Jambor Sent: Friday, July 3, 2020 1:59 AM To: Gary Oblock ; Richard Biener Cc: gcc@gcc.gnu.org Subject: Re: An problematic interaction between a call created by gimple_build_call and inlining Hi, On Thu, Jul 02 2020, Gary Oblock wrote: > Martin, > > What about immediate dominators? I'm afraid I don't understand your question, what about them? Dominators are re-computed after inlining and after clones are materialized (when they get their own body)... I believe. We do not store information which call graph edges dominate other call graph edges in the callers body. Having that information might be useful at IPA stage. But yeah, please be more specific what your question is. Martin > > > From: Martin Jambor > Sent: Wednesday, July 1, 2020 3:40 PM > To: Gary Oblock ; Richard Biener > > Cc: gcc@gcc.gnu.org > Subject: Re: An problematic interaction between a call created by > gimple_build_call and inlining > > [EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please > be mindful of safe email handling and proprietary information protection > practices.] > > > Hi, > > On Wed, Jul 01 2020, Gary Oblock via Gcc wrote: >> Thank you Richard. >> >> I feel a bit dumb because I'm well aware of the GCC philosophy to have >> any new code produced update the state. Of course I didn't know the >> commands to do this for the call graph (which I really appreciate you >> giving.) >> >> However, the real reason I'm sending a reply is this. Are there any >> surprising >> cases in IPA where GCC violates its philosophy and actually regenerates the >> information? > > if by "the information" you specifically mean call graph edges then no. > (Regular) IPA optimizations are designed to also work when doing link > time optimization (LTO) which means that unless they specifically load > the (gimple) bodies of some selected functions, the bodies are not > available to them. They only operate on the call graph and information > they collected when generating summaries. Because gimple body is not > available, call graph edges cannot be regenerated from it. > > In fact, when a call is redirected to a different/specialized function, > at IPA time it is only recored in the call graph by redirecting the > corresponding edge and the call statement is modified only at the end of > IPA phase (in LTRANS in LTO-speak). This is necessary even when not > using LTO because until specialized nodes get their own body, they share > it with the node from which they were cloned. That means that several > call graph edges, which do not share caller and may not even share the > callee, refer to the same gimple statement - so the decl in the > statement is actually meaningless and the edge encodes the important > information. > > Martin
