Question on updating function body on specialized functions
Hi, I have one function (F) that has been specialized for two different calling contexts (F1 and F2) and two late SIMPLE_IPA_PASSes (A and B). Pass A changes some MEM_REFs such that the type of MEM_REF is compatible with the type of the first operand of the expression. Pass A changes both F1 and F2. I have printed the function bodies of both F1 and F2 during Pass A and everything looks correct. Pass B uses these changes. However I noticed this interesting behaviour: 1. If I fix F1 first and then F2, then pass B will see F2 correctly but some of F1 MEM_REFs will be incorrect. 2. If I fix F2 first and then F1, then pass B will see F1 correctly but some of F2 MEM_REFs will be incorrect. My question is do different specialized functions share the same trees? How would I then change the bodies of specialized functions? Thanks!
Re: OpenMP auto-simd
Hi! ... with the usual caveat that I know much more about OpenACC than OpenMP, and I know (at least a bit) more about nvptx than GCN... ;-) On 2022-03-02T15:12:30+, "Stubbs, Andrew" wrote: > Has anyone ever considered having GCC add the "simd" clause to offload (or > regular) loop nests automatically? > > For example, something like "-fomp-auto-simd" would transform "distribute > parallel" to "distribute parallel simd" automatically. Loop nests that > already contain "simd" clauses or directives would remain unchanged, most > likely. > > The reason I ask is that other toolchains have chosen to use a "SIMT" model > for GPUs, which means that OpenMP threads map to individual vector lanes and > are therefore are strictly scalar. The result is that the "simd" directive is > irrelevant and lots of code out there isn't using it at all (so I'm told). > Meanwhile, in GCC we map OpenMP threads to Nvidia warps and AMD GCN > wavefronts, so it is impossible to get full performance without explicitly > specifying the "simd" directive. We therefore suffer in direct comparisons. > > I'm of the opinion that GCC is the one implementing OpenMP as intended I'm curious: how does one arrive at this conclusion? For example, in addition to intra-warp thread parallelism, nvptx also does have a few SIMD instructions: data transfer (combine two adjacent 32-bit transfers into one 64-bit transfer, and also some basic arithmetic; I'd have to look up the details). It's not much, but it's something that GCC's SLP vectorizer can use. (Tom worked on that, years ago.) Using that to implement OpenMP's SIMD (quite likely via default-(SLP-)auto-vectorization), you'd then indeed get for actualy OpenMP threads what you described as "SIMT" model above. Why not change GCC to do the same, if that's the common understanding how OpenMP for GPUs should be done, as implemented by other compilers? Grüße Thomas > but all the same I need to explore our options here, figure out what the > consequences would be, and plan a project to do what we can. > > I've thought of simply enabling "-ftree-vectorize" on AMD GCN (this doesn't > help NVPTX) but I think that is sub-optimal because things like the OpenMP > scheduler really need to be aware of the vector size, and there's probably > other ways in which parallel regions can be better formed with regard to the > vectorizer. If these features don't exist right now then I have an > opportunity to include them in our upcoming project. > > Any info/suggestions/advice would be appreciated. > > Thanks > > Andrew - Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955
Re: Question on updating function body on specialized functions
Hi Erik, On Tue, Mar 08 2022, Erick Ochoa via Gcc wrote: > Hi, > > I have one function (F) that has been specialized for two different calling > contexts (F1 and F2) and two late SIMPLE_IPA_PASSes (A and B). Pass A > changes some MEM_REFs such that the type of MEM_REF is compatible with the > type of the first operand of the expression. Pass A changes both F1 and F2. > I have printed the function bodies of both F1 and F2 during Pass A and > everything looks correct. Pass B uses these changes. > > However I noticed this interesting behaviour: > > 1. If I fix F1 first and then F2, then pass B will see F2 correctly but > some of F1 MEM_REFs will be incorrect. > 2. If I fix F2 first and then F1, then pass B will see F1 correctly but > some of F2 MEM_REFs will be incorrect. > I try to avoid SIMPLE_IPA_PASSes and so would have to look how exactly they fit into the big picture. Also, I am not sure what you mean by "incorrect" above (modified when you'd not have expected it to be)? > My question is do different specialized functions share the same trees? How > would I then change the bodies of specialized functions? Virtual clones are, until they are "materialized." But it a simple IPA pass it does not really make sense to create virtual clones, does it? Do you create your clones with create_version_clone_with_body? Martin
Re: Question on updating function body on specialized functions
Hi Martin! Thanks for replying, turns out that while I was trying to reply to you I was able to get the answer. Turns out there is indeed one tree node which is shared across the two functions. And that is TREE_OPERAND (MEM_REF, 1). When I was assigning to TREE_TYPE ( TREE_OPERAND (MEM_REF, 1) ) in one function, I was modifying the other. The solution was to create a new tree and assign it directly to TREE_OPERAND (MEM_REF, 1) in both functions. Thanks!
Re: Porting the Docs to Sphinx - project status
On 2/4/22 14:40, Matthias Klose wrote: On 1/31/22 15:06, Martin Liška wrote: Hello. It's about 5 months since the last project status update: https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577108.html Now it's pretty clear that it won't be merged before GCC 12.1 gets released. So where we are? I contacted documentation maintainers (Gerald, Sandra and Joseph) at the end of the year in a private email, where I pinged the patches. My take away is that both Gerald and Joseph are fine with the porting, while Sandra has some concerns. Based on her feedback, I was able to improve the PDF generated output significantly and I'm pleased by the provided feedback. That led to the following 2 Sphinx pulls requests that need to be merged before we can migrate the documentation: [1], [2]. Since the last time I also made one more round of proofreading and the layout was improved (mainly for PDF part). Current version of the documentation can be seen here: https://splichal.eu/scripts/sphinx/ I would like to finish the transition once GCC 12.1 gets released in May/June this year. There are still some minor regressions, but overall the Sphinx-based documentation should be a significant improvement over what we've got right now. Please take this email as urgent call for a feedback! Please take care about the copyrights. I only checked the D frontend manual, and this one suddenly has a copyright with invariant sections, compared to the current gdc.texi which has a copyright *without* the invariant sections. Debian doesn't allow me to ship documentation with invariant sections ... Oh, thank you very much for the pointer. I didn't notice the Copyright sections differ quite a lot. It should be fixed now. I didn't look how much you reorganized the sources, but it would nice to split the files into those documenting command line options (used to generate the man pages) and other documentation. Well, the current splitting is done into multiple .rst files and a bunch of them actually constructs command line options. Please check View page source button on each HTML page. This is already done for gcc/doc, but not for other frontends. It would allow having manual pages with a copyright requiring front and back cover texts in the manual pages. How exactly does it work? Does it mean you don't use official GCC tarballs? I would expect you just package built man/info pages and don't distribute PDF/HTML version of a documenation, or? It would also be nice to require the latest sphinx version (and probably some plugins), so that distros can build the docs with older sphinx versions as well. I'm sorry but this would be very difficult. It's mainly caused by fact I've reported quite some changes to upstream, where having them leads to a reasonable HTML/PDF output. Note you can quite easily utilize pip&virtualenv for Sphinx installation. Cheers, Martin Matthias
RE: OpenMP auto-simd
> > I'm of the opinion that GCC is the one implementing OpenMP as intended > > I'm curious: how does one arrive at this conclusion? Basically, any implementation for which a (significant) directive becomes a no-op is either a) not implementing the feature as intended, or b) is implementing it for a device configured differently to the one that inspired the directive. Since I'm pretty sure that (b) is not the case I settled my opinion on (a). Now, it may be that the original intention is flawed and the deviant implementation is superior, but that's another matter. Andrew
LTO lto_priv duplicate symbol and the reason for it
Hi GCC community, I have a few questions that I am struggling to find an answer for: a. Why does LTO generates a new symbol? b. Why it does not replace the existing symbol, instead of creating a new one with "lto_priv.%d" at the end of it [1]? c. Can we assume the original symbol always will be removed? Or it is possible to have cases where we have _x_ and _x_.lto_priv.0 together in the final binary? 1. https://github.com/gcc-mirror/gcc/blob/master/gcc/lto/lto-partition.cc#L937 Best wishes, Navid.
Re: Question on updating function body on specialized functions
Erick my friend, That's exactly why I'm such a big fan of creating things anew each time I mess with them. 😉 Later, Gary From: Erick Ochoa Sent: Tuesday, March 8, 2022 7:29 AM To: Martin Jambor Cc: gcc@gcc.gnu.org Subject: Re: Question on updating function body on specialized functions Hi Martin! Thanks for replying, turns out that while I was trying to reply to you I was able to get the answer. Turns out there is indeed one tree node which is shared across the two functions. And that is TREE_OPERAND (MEM_REF, 1). When I was assigning to TREE_TYPE ( TREE_OPERAND (MEM_REF, 1) ) in one function, I was modifying the other. The solution was to create a new tree and assign it directly to TREE_OPERAND (MEM_REF, 1) in both functions. Thanks!
