State of AutoFDO in GCC
GCC documentation for AutoFDO points to create_gcov tool that converts perf.data file into gcov format that can be consumed by gcc with -fauto-profile (https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html, https://gcc.gnu.org/wiki/AutoFDO/Tutorial). I noticed that the source code for create_gcov has been deleted from https://github.com/google/autofdo on April 7. I asked about that change in that repo and got the following reply: https://github.com/google/autofdo/pull/107#issuecomment-819108738 "Actually we didn't use create_gcov and havn't updated create_gcov for years, and we also didn't have enough tests to guarantee it works (It was gcc-4.8 when we used and verified create_gcov). If you need it, it is welcomed to update create_gcov and add it to the respository." Does this mean that AutoFDO is currently dead in gcc? Thanks, Eugene
Re: State of AutoFDO in GCC
On 4/22/21 9:58 PM, Eugene Rozenfeld via Gcc wrote: > GCC documentation for AutoFDO points to create_gcov tool that converts > perf.data file into gcov format that can be consumed by gcc with > -fauto-profile (https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html, > https://gcc.gnu.org/wiki/AutoFDO/Tutorial). > > I noticed that the source code for create_gcov has been deleted from > https://github.com/google/autofdo on April 7. I asked about that change in > that repo and got the following reply: > > https://github.com/google/autofdo/pull/107#issuecomment-819108738 > > "Actually we didn't use create_gcov and havn't updated create_gcov for years, > and we also didn't have enough tests to guarantee it works (It was gcc-4.8 > when we used and verified create_gcov). If you need it, it is welcomed to > update create_gcov and add it to the respository." > > Does this mean that AutoFDO is currently dead in gcc? Hello. Yes. I know that even basic test cases have been broken for years in the GCC. It's new to me that create_gcov was removed. I tend to send patch to GCC that will remove AutoFDO from GCC. I known Bin spent some time working on AutoFDO, has he came up to something? Martin > > Thanks, > > Eugene >
Re: removing toxic emailers
On 15/04/2021 10:40 am, Frosku wrote: On Wed Apr 14, 2021 at 9:49 PM BST, Paul Koning via Gcc wrote: My answer is "it depends". More precisely, in the past I would have favored those who decline because the environment is unpleasant -- with the implied assumption being that their objections are reasonable. Given the emergency of cancel culture, that assumption is no longer automatically valid. This is why I asked the question "who decides?" Given a disagreement in which the proposed remedy is to ostracise a participant, it is necessary to inquire for what reason this should be done (and, perhaps, who is pushing for it to be done). My suggestion is that this judgment can be made by the community (via secret ballot), unless it is decided to delegate that power to a smaller body, considered as trustees, or whatever you choose to call them. paul I think, in general, it's fine to leave this decision to moderators. It's just a little disconcerting when one of the people who would probably be moderating is saying that he could have shut down the discussion if he could only ban jerks, as if to imply that everyone who dares to disagree with his position is a jerk worthy of a ban. A little late to the party, but thought this was worth commenting on- from my perspective, as long as there is some sort of consensus amongst moderators about who is worth banning, as opposed to whether it can be fixed by calling the person out on their ongoing behaviour, it's probably worth doing. If that power is left to one mod, it's not a good thing. 3 or a larger odd number of mods is best for avoiding stalemates, and more is better. As an example of a controversial mod choice and without wanting to reopen wounds here, if I were a mod I could quite easily ban Nathan for the dishonesty and divisiveness of his initial post (see below if you require substantive talk around that), despite the fact that I have no particular love for Stallman or any investment in the topic. But another mod might see that contribution as 'the end justifying the means' in terms of bringing in an inevitable debate around Stallman's offputting personal manner, and whether that fits in today's society. Another mod might have another opinion etc. Two or three heads, are better than one, when it comes to behaviour judgement - particularly when an international community is at stake. And the more temperamentally/culturally diverse the mods are - the better for decision-making overall. = 1. 'skeptical that voluntarily pedophilia harms children.’ stallman's own archives 2006-mar-jun I note that children are *incapable* of consenting. That’s what the age of consent means. He has recanted on this as of 2019 (https://www.stallman.org/archives/2019-jul-oct.html#14_September_2019_(Sex_between_an_adult_and_a_child_is_wrong)) because people took the time to point out to him why his opinion was wrong. Omitting his recantation is, by my standards, a lie by omission. It doesn't make what he initially said any less terrible. But it clarifies his actual position. 2. 'end censorship of “child pornography”’. Stallman's archives 2012-jul-oct.html Notice use of “quotes” to down play what is actually being requested. While I don't actually agree with Stallman in the slightest, his stated objection is "it's common practice for teenagers to exchange nude photos with their lovers, and they all potentially could be imprisoned for this. A substantial fraction of them are actually prosecuted. " That's very different from how it's been presented here - a lie by omission. 3. 'gentle expressions of attraction’ Stallman's archives > 2012-jul-oct.html Condoning a variant of the wolf-whistle. Unless one’s talking to one’s lover, ‘gentle invitations for sex’ by a stranger is *grooming* (be it child or of-age). If you ever been to a bar, or an open-air event, or god forbid a party, you are aware that this is an obvious lie (for adults). Secondarily, nothing in Richard's text relates to wolf-whistling or variants.
Re: State of AutoFDO in GCC
> On 4/22/21 9:58 PM, Eugene Rozenfeld via Gcc wrote: > > GCC documentation for AutoFDO points to create_gcov tool that converts > > perf.data file into gcov format that can be consumed by gcc with > > -fauto-profile (https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html, > > https://gcc.gnu.org/wiki/AutoFDO/Tutorial). > > > > I noticed that the source code for create_gcov has been deleted from > > https://github.com/google/autofdo on April 7. I asked about that change in > > that repo and got the following reply: > > > > https://github.com/google/autofdo/pull/107#issuecomment-819108738 > > > > "Actually we didn't use create_gcov and havn't updated create_gcov for > > years, and we also didn't have enough tests to guarantee it works (It was > > gcc-4.8 when we used and verified create_gcov). If you need it, it is > > welcomed to update create_gcov and add it to the respository." > > > > Does this mean that AutoFDO is currently dead in gcc? > > Hello. > > Yes. I know that even basic test cases have been broken for years in the GCC. > It's new to me that create_gcov was removed. > > I tend to send patch to GCC that will remove AutoFDO from GCC. > I known Bin spent some time working on AutoFDO, has he came up to something? The GCC side of auto-FDO is not that hard. We have most of infrastructure in place, but stopping point for me was always difficulty to get gcov-tool working. If some maintainer steps up, I think I can fix GCC side. I am bit unsure how important feature it is - we have FDO that works quite well for most users but I know there are some users of the LLVM implementation and there is potential to tie this with other hardware events to asist i.e. if conversion (where one wants to know how well CPU predicts the jump rather than just the jump probability) which I always found potentially interesting. Honza > > Martin > > > > > Thanks, > > > > Eugene > > >
gcc-8-20210422 is now available
Snapshot gcc-8-20210422 is now available on https://gcc.gnu.org/pub/gcc/snapshots/8-20210422/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 8 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-8 revision ef195a39d0d3b929cc676302d074b42c25460601 You'll find: gcc-8-20210422.tar.xzComplete GCC SHA256=036c1791606429af7ce0075e3cbf2b582fe987cd49f8b42d17fe327f19e5f787 SHA1=e3ea5f9f50ab458368534261d7c36bd58bdfa822 Diffs from 8-20210415 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-8 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: State of AutoFDO in GCC
On Fri, Apr 23, 2021 at 4:16 AM Martin Liška wrote: > > On 4/22/21 9:58 PM, Eugene Rozenfeld via Gcc wrote: > > GCC documentation for AutoFDO points to create_gcov tool that converts > > perf.data file into gcov format that can be consumed by gcc with > > -fauto-profile (https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html, > > https://gcc.gnu.org/wiki/AutoFDO/Tutorial). > > > > I noticed that the source code for create_gcov has been deleted from > > https://github.com/google/autofdo on April 7. I asked about that change in > > that repo and got the following reply: > > > > https://github.com/google/autofdo/pull/107#issuecomment-819108738 > > > > "Actually we didn't use create_gcov and havn't updated create_gcov for > > years, and we also didn't have enough tests to guarantee it works (It was > > gcc-4.8 when we used and verified create_gcov). If you need it, it is > > welcomed to update create_gcov and add it to the respository." > > > > Does this mean that AutoFDO is currently dead in gcc? > > Hello. > > Yes. I know that even basic test cases have been broken for years in the GCC. > It's new to me that create_gcov was removed. > > I tend to send patch to GCC that will remove AutoFDO from GCC. > I known Bin spent some time working on AutoFDO, has he came up to something? Hi Martin, I haven't touched this part for quite some time. I have no objection to removing it from GCC. However, I do have general concern that because of fewer users/developers, it's less likely and harder for new features to land in GCC. I have no idea if this is a real problem or how to fix it. OTOH, maybe removing rotten features, making GCC more(?) concise, and improving existing features that GCC is doing well is the right thing. Thanks, bin > > Martin > > > > > Thanks, > > > > Eugene > > >
Re: State of AutoFDO in GCC
Hi, the create_gcov tool was probably removed with the assumption that it was only used with Google GCC branch, but it is actually used with GCC trunk as well. Given that, the tool will be restored in the github repo. It seems to build and work fine with the regression test. The tool may ust work as it is right now, but there is no guarantee it won't break in the future unless someone in the GCC community tries to maintain it. Thanks, David On Thu, Apr 22, 2021 at 3:29 PM Jan Hubicka wrote: > > On 4/22/21 9:58 PM, Eugene Rozenfeld via Gcc wrote: > > > GCC documentation for AutoFDO points to create_gcov tool that converts > perf.data file into gcov format that can be consumed by gcc with > -fauto-profile (https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html, > https://gcc.gnu.org/wiki/AutoFDO/Tutorial). > > > > > > I noticed that the source code for create_gcov has been deleted from > https://github.com/google/autofdo on April 7. I asked about that change > in that repo and got the following reply: > > > > > > https://github.com/google/autofdo/pull/107#issuecomment-819108738 > > > > > > "Actually we didn't use create_gcov and havn't updated create_gcov for > years, and we also didn't have enough tests to guarantee it works (It was > gcc-4.8 when we used and verified create_gcov). If you need it, it is > welcomed to update create_gcov and add it to the respository." > > > > > > Does this mean that AutoFDO is currently dead in gcc? > > > > Hello. > > > > Yes. I know that even basic test cases have been broken for years in the > GCC. > > It's new to me that create_gcov was removed. > > > > I tend to send patch to GCC that will remove AutoFDO from GCC. > > I known Bin spent some time working on AutoFDO, has he came up to > something? > > The GCC side of auto-FDO is not that hard. We have most of > infrastructure in place, but stopping point for me was always difficulty > to get gcov-tool working. If some maintainer steps up, I think I can > fix GCC side. > > I am bit unsure how important feature it is - we have FDO that works > quite well for most users but I know there are some users of the LLVM > implementation and there is potential to tie this with other hardware > events to asist i.e. if conversion (where one wants to know how well CPU > predicts the jump rather than just the jump probability) which I always > found potentially interesting. > > Honza > > > > Martin > > > > > > > > Thanks, > > > > > > Eugene > > > > > >
