Re: [RFC] Analysis of PR105586 and possible approaches to fix issue

[Richard Biener via Gcc]

On Tue, Jul 26, 2022 at 8:55 PM Surya Kumari Jangala via Gcc
 wrote:
>
> Hi,
> I am working on PR105586. This is a -fcompare-debug failure, with the 
> differences starting during sched1 pass. The sequence of two instructions in 
> a basic block (block 4) is flipped with -g.
> In addition to this, another difference is that an insn is assigned a 
> different cycle in debug vs non-debug modes.
> More specifically, the 2nd instruction in basic block 4 is assigned to cycle 
> 0 w/o -g but to cycle 1 w/ -g. I felt that this could be resulting in the 
> flipping of the later insns in the bb, so I started to investigate the 
> difference in cycle assignment.
>
> In the routine schedule_block(), after scheduling an insn(schedule_insn()), 
> prune_ready_list() is called if the ready list is not empty. This routine 
> goes thru all the insns in the ready list and for each insn it checks if 
> there is a state transition. If there is no state transition, then 
> INSN_TICK(insn) is set to current_cycle+1.
>
> After scheduling the first insn in bb 4, when prune_ready_list() is called, 
> we see that for the debug mode run, there is no state transition for the 
> second insn and hence it's INSN_TICK is updated. For the non-debug run, a 
> state transition exists and the INSN_TICK is not updated. This was resulting 
> in the second insn being scheduled in cycle 1 in the debug mode, and in cycle 
> 0 in the non-debug mode.
>
> It turned out that the initial dfa state of the basic block (‘init_state’ 
> parameter of schedule_block()) was different in debug and non-debug modes.
>
> After scheduling a basic block, it’s current dfa state is copied to the 
> fall-thru basic block. In other words, the initial dfa state of the fall thru 
> bb is the current state of the bb that was just scheduled.
>
> Basic block 4 is the fall-thru bb for basic block 3. In non-debug mode, bb 3 
> has only a NOTE insn and hence scheduling of bb 3 is skipped. Since bb 3 is 
> not scheduled, it’s state is not copied to bb 4. Whereas in debug mode, bb3 
> has a NOTE insn and a DEBUG insn. So bb 3 is “scheduled” and it’s dfa state 
> is copied to bb4. [The dfa state of bb 3 is obtained from it’s parent bb, ie, 
> bb 2]. Hence the initial dfa state of bb 4 is different in debug and 
> non-debug modes due to the difference in the insns in the predecessor bb (bb 
> 3).
>
> The routine no_real_insns_p() is called to check if scheduling can be skipped 
> for a basic block. This routine checks for NOTE and LABEL insns and it 
> returns ‘true’ if a basic block contains only NOTE/LABEL insns. Hence, any 
> basic block which has only NOTE or LABEL insns is not scheduled.
>
> To fix the issue of insns being assigned different cycles, there are two 
> possible solutions:
>
> 1. Modify no_real_insns_p() to treat a DEBUG insn as a non-real insn (similar 
> to NOTE and LABEL). With this change, bb 3 will not be scheduled in the debug 
> mode (as it contains only NOTE and DEBUG insns). If scheduling is skipped, 
> then bb 3’s state is not copied to bb 4 and the initial dfa state of bb 4 
> will be same in both debug and non-debug modes
> 2. Copy dfa state of a basic block to it’s fall-thru block only if the basic 
> block contains ‘real’ insns (ie, it should contain at least one insn which is 
> not a LABEL, NOTE or DEBUG). This will prevent copying of dfa state from bb 3 
> to bb 4 in debug mode.

Do you know why the DFA state is not always copied to the fallthru
destination and then copied further even if the block does not contain
any (real) insns?  It somewhat sounds like premature optimization
breaking things here...

> I decided to take approach 1 and I changed no_real_insns_p() to check for 
> DEBUG insns in addition to NOTE and LABEL insns.
>
> But this resulted in an internal compiler error in the bug's testcase. The 
> reason was that dependency nodes and lists of the insns in a basic block are 
> not freed after the bb is scheduled. The routine sched_analyze() allocates 
> dependency nodes and lists for each insn in an extended basic block only if 
> the insn is NONDEBUG_INSN or DEBUG_INSN. So in debug mode, the scheduler 
> allocated dependencies for bb 3 but in non-debug mode, there are no 
> dependencies allocated. The dependencies are freed after all the blocks in a 
> region are scheduled. But the routine to free the dependencies is called for 
> a bb only if no_real_insns_p() returns true for that bb. With approach 1, 
> no_real_insns_p() returns true for bb 3 and hence the dependencies are not 
> freed.
>
> I added some code to not create dependencies if a bb contains only NOTE, 
> LABEL and DEBUG insns. This makes the test pass but I am hitting an internal 
> compiler error during bootstrapping.
>
> I wish to get some inputs/feedback if approach 1 is the correct way to fix 
> the issue, or should I take approach 2.
>
> Thanks,
> Surya

Re: State of AutoFDO in GCC

[Jan Hubicka via Gcc]

> On Tue, Jul 26, 2022 at 4:13 PM Eugene Rozenfeld via Gcc
>  wrote:
> >
> > Hello GCC community.
> >
> > I started this thread on the state of AutoFDO in GCC more than a year ago. 
> > Here is the first message in the thread: 
> > https://gcc.gnu.org/pipermail/gcc/2021-April/235860.html
> >
> > Since then I committed a number of patches to revive AutoFDO in GCC:
> >
> > Fix a typo in an AutoFDO error 
> > string
> > Update gen_autofdo_event.py and 
> > gcc-auto-profile.
> > Fixes for AutoFDO 
> > tests
> > Fix indir-call-prof-2.c with 
> > AutoFDO
> > Fixes for AutoFDO 
> > testing
> > Fix indirect call inlining with 
> > AutoFDO
> > Improve AutoFDO count propagation 
> > algorithm
> > AutoFDO: don't set param_early_inliner_max_iterations to 
> > 10.
> > AutoFDO: Don't try to promote indirect calls that result in recursive 
> > direct 
> > calls
> > Fix profile count maintenance in vectorizer 
> > peeling.
> >
> > I also made a number of fixes and improvements to create_gcov tool in 
> > https://github.com/google/autofdo .
> >
> > AutoFDO in GCC is in a much better shape now.
> >
> > I have a further set of patches that improve DWARF discriminator support in 
> > GCC and enable AutoFDO to use discriminators. It's based on commits in an 
> > old Google vendor branch as described in Andi's mail below
> > but uses a different approach for keeping track of per-instruction 
> > discriminators.
> >
> > I submitted the first (and the biggest) of these patches almost 2 months 
> > ago on June 2: 
> > https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=5af22024f62f1f596a35d3c138d41d47d5697ca0
> > but only got a review from Andi 
> > (https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596549.html) who is 
> > not allowed to approve patches for commit. I pinged gcc-patches twice with 
> > no success.
> >
> > I would appreciate help in getting a review on this patch so that I can get 
> > it committed and submit patches that depend on it.
> 
> Hi, Eugene
> 
> Thanks for your efforts to fix and improve AutoFDO in GCC.  I believe
> that part of the difficulty with obtaining a review of the patches is
> that the original authors have dispersed and no one in the GCC
> community officially is the maintainer for the feature.  Because you
> seem to be one of the primary users and developers, would you be
> interested to take on the responsibility of maintaining the
> AutoFDO-specific portions of the code, with guidance and mentorship
> from other GCC maintainers, especially the ones responsible for gcov
> and PDO?

I missed the patches (it would help to add me to CC :) and will review
the FDO/profile facing parts.  Since it also extends debug info
generation and front-ends I think we also need reviewer for that part.

Having auto-FDO co-maintainer would be welcome.

Honza
> 
> Thanks, David
> 
> >
> > Thank you,
> >
> > Eugene
> >
> > -Original Message-
> > From: Andi Kleen 
> > Sent: Monday, May 10, 2021 10:21 AM
> > To: Joseph Myers 
> > Cc: Jan Hubicka ; gcc ; Eugene Rozenfeld 
> > 
> > Subject: [EXTERNAL] Re: State of AutoFDO in GCC
> >
> > On Mon, May 10, 2021 at 04:55:50PM +, Joseph Myers wrote:
> > > On Mon, 10 May 2021, Andi Kleen via Gcc wrote:
> > >
> > > > It's difficult to find now because it was a branch in the old SVN
> > > > that wasn't converted. Sadly the great git conversion was quite lossy.
> > >
> > > All branches and tags, including deleted ones, were converted (under
> > > not-fetched-by-default refs in some cases); the git repository has
> > > everything that might plausibly be useful, omitting only a few things
> > > that would have been meaningless to convert, such as mistaken branch
> > > creations in the root of the repository and the SVN hooks directory.
> > > Use "git ls-remote git://gcc.gnu.org/git/gcc.git" to see the full list
> > > of over 5000 refs available in the repository (or do a clone with
> > > --mirror to fetch them all).
> >
> > Okay thanks. I don't see them in any of the web interfaces, neither on
> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc.gnu.org%2Fgit%2Fgitweb.cgi%3Fp%3Dgcc.git&d

GCC 12.1.1 Status Report (2022-07-27)

[Richard Biener via Gcc]

Status
==

The gcc-12 branch is open for regression and documentation fixes.

It is time for a GCC 12.2 release, we are comparatively late with it
already.  The plan is to create a GCC 12.2 release candidate on
August 12th which should give plenty of time to backport or implement
important regression fixes.

Please make sure your primary and secondary targets are in good
shape for this release.


Quality Data


Priority  #   Change from last report
---   ---
P1  0  
P2  429   +  62
P3  63-  22
P4  240   -   8
P5  25-   1
---   ---
Total P1-P3 492   +  40
Total   757   +  31


Previous Report
===

https://gcc.gnu.org/pipermail/gcc/2022-May/238654.html

[RISCV] RISC-V GNU Toolchain Meeting Cancell (July, 28, 2022)

[jiawei]

Hi all,



Tomorrow meeting will cancel since there are few new topics to discuss.  

   


The next meeting will be two weeks later, and we are collecting the themes.




If you have any questions want to discuss please mail me and I will add it 
into 

the agenda for next meeting.





Best wishes,

Jiawei

Re: [RFC] Analysis of PR105586 and possible approaches to fix issue

[Surya Kumari Jangala via Gcc]

Hi Richard,

On 27/07/22 12:28 pm, Richard Biener wrote:
> On Tue, Jul 26, 2022 at 8:55 PM Surya Kumari Jangala via Gcc
>  wrote:

>> To fix the issue of insns being assigned different cycles, there are two 
>> possible solutions:
>>
>> 1. Modify no_real_insns_p() to treat a DEBUG insn as a non-real insn 
>> (similar to NOTE and LABEL). With this change, bb 3 will not be scheduled in 
>> the debug mode (as it contains only NOTE and DEBUG insns). If scheduling is 
>> skipped, then bb 3’s state is not copied to bb 4 and the initial dfa state 
>> of bb 4 will be same in both debug and non-debug modes
>> 2. Copy dfa state of a basic block to it’s fall-thru block only if the basic 
>> block contains ‘real’ insns (ie, it should contain at least one insn which 
>> is not a LABEL, NOTE or DEBUG). This will prevent copying of dfa state from 
>> bb 3 to bb 4 in debug mode.
> 
> Do you know why the DFA state is not always copied to the fallthru
> destination and then copied further even if the block does not contain

I am not sure why the DFA state is not always copied to the fallthru 
destination. It is not very apparent from the code.

> any (real) insns?  It somewhat sounds like premature optimization
> breaking things here...
> 

Now that you mention it, yes it does seem suboptimal that the DFA state is not 
always copied. I don’t see any reason why the DFA state shouldn’t be always 
copied. And I think this is the fix for this bug. '-g' mode is behaving 
correctly, it is the non-debug mode which is incorrect.

Thanks,
Surya

RE: [EXTERNAL] Re: State of AutoFDO in GCC

[Eugene Rozenfeld via Gcc]

Hi David,

Thank you for your offer to take on the responsibility of maintaining the 
AutoFDO-specific portions of the code. I'll be happy to do that with Jan's and 
other GGC maintainers' help.
I hope more people will start using and contributing to AutoFDO.

Thanks,

Eugene

-Original Message-
From: David Edelsohn  
Sent: Tuesday, July 26, 2022 3:38 PM
To: Eugene Rozenfeld ; Jan Hubicka 
; Martin Liska ; Xinliang David Li 

Cc: Andi Kleen ; Joseph Myers ; 
gcc 
Subject: [EXTERNAL] Re: State of AutoFDO in GCC

[You don't often get email from dje@gmail.com. Learn why this is important 
at https://aka.ms/LearnAboutSenderIdentification ]

On Tue, Jul 26, 2022 at 4:13 PM Eugene Rozenfeld via Gcc  
wrote:
>
> Hello GCC community.
>
> I started this thread on the state of AutoFDO in GCC more than a year 
> ago. Here is the first message in the thread: 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc.
> gnu.org%2Fpipermail%2Fgcc%2F2021-April%2F235860.html&data=05%7C01%
> 7CEugene.Rozenfeld%40microsoft.com%7Ccabaec504f234632a03a08da6f5780d2%
> 7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637944718882043585%7CUnkn
> own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
> LCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=5RoiLypTlkNRIZW8yAufYR4qiO573
> 0PADO%2BFsS6InIU%3D&reserved=0
>
> Since then I committed a number of patches to revive AutoFDO in GCC:
>
> Fix a typo in an AutoFDO error 
> string %2Fgcc.gnu.org%2Fgit%2F%3Fp%3Dgcc.git%3Ba%3Dcommit%3Bh%3D23691ddd3aa3f
> fe55892b2bff54f9a15a89de2b4&data=05%7C01%7CEugene.Rozenfeld%40micr
> osoft.com%7Ccabaec504f234632a03a08da6f5780d2%7C72f988bf86f141af91ab2d7
> cd011db47%7C1%7C0%7C637944718882199821%7CUnknown%7CTWFpbGZsb3d8eyJWIjo
> iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%
> 7C%7C&sdata=LRgW4qyh%2FAdrlKluUXnaDTFCNW8tnS1WX8bCs1WAT7s%3D&r
> eserved=0> Update gen_autofdo_event.py and 
> gcc-auto-profile. https%3A%2F%2Fgcc.gnu.org%2Fgit%2F%3Fp%3Dgcc.git%3Ba%3Dcommit%3Bh%3D01
> d402c5e0ac1ddf5618bbe316b50067625fda46&data=05%7C01%7CEugene.Rozen
> feld%40microsoft.com%7Ccabaec504f234632a03a08da6f5780d2%7C72f988bf86f1
> 41af91ab2d7cd011db47%7C1%7C0%7C637944718882199821%7CUnknown%7CTWFpbGZs
> b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
> %7C3000%7C%7C%7C&sdata=oBJvTW6RrkY6uURmr0UK5gaNiVS1b8vFfIyOoqq8AkM
> %3D&reserved=0> Fixes for AutoFDO 
> tests 2Fgcc.gnu.org%2Fgit%2F%3Fp%3Dgcc.git%3Ba%3Dcommit%3Bh%3Df9ad3d5339faaa
> ed6e15a7b27d90fbc66eb72f37&data=05%7C01%7CEugene.Rozenfeld%40micro
> soft.com%7Ccabaec504f234632a03a08da6f5780d2%7C72f988bf86f141af91ab2d7c
> d011db47%7C1%7C0%7C637944718882199821%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7
> C%7C&sdata=6evlP10%2BQJyUuVZ3u%2Fv%2FP9nSIsASLjtWETyqeBfnQ2k%3D&am
> p;reserved=0> Fix indir-call-prof-2.c with 
> AutoFDO F%2Fgcc.gnu.org%2Fgit%2F%3Fp%3Dgcc.git%3Ba%3Dcommit%3Bh%3D0ed093c7c3f7
> 55bc1cd80e5186abeb2f5c50ee0c&data=05%7C01%7CEugene.Rozenfeld%40mic
> rosoft.com%7Ccabaec504f234632a03a08da6f5780d2%7C72f988bf86f141af91ab2d
> 7cd011db47%7C1%7C0%7C637944718882199821%7CUnknown%7CTWFpbGZsb3d8eyJWIj
> oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C
> %7C%7C&sdata=mtMd21By6r8DiIIXzk5ePHP0iU%2FHfnDQG8%2FXJbAr5qE%3D&am
> p;reserved=0> Fixes for AutoFDO 
> testing F%2Fgcc.gnu.org%2Fgit%2F%3Fp%3Dgcc.git%3Ba%3Dcommit%3Bh%3D9265b3785313
> 91498ec1727f67a45da72a6c07e9&data=05%7C01%7CEugene.Rozenfeld%40mic
> rosoft.com%7Ccabaec504f234632a03a08da6f5780d2%7C72f988bf86f141af91ab2d
> 7cd011db47%7C1%7C0%7C637944718882199821%7CUnknown%7CTWFpbGZsb3d8eyJWIj
> oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C
> %7C%7C&sdata=QnKrxt7W9wfTYY3Drjm%2FSn7D4yHwxjInvI8dj9KEIs4%3D&
> reserved=0> Fix indirect call inlining with 
> AutoFDO F%2Fgcc.gnu.org%2Fgit%2F%3Fp%3Dgcc.git%3Ba%3Dcommit%3Bh%3D285aa6895d47
> 9bed8e72ad363290846645b6faa0&data=05%7C01%7CEugene.Rozenfeld%40mic
> rosoft.com%7Ccabaec504f234632a03a08da6f5780d2%7C72f988bf86f141af91ab2d
> 7cd011db47%7C1%7C0%7C637944718882199821%7CUnknown%7CTWFpbGZsb3d8eyJWIj
> oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C
> %7C%7C&sdata=695ieVftlFRwICzxxMmmIb9%2F%2FDBlYBy9jJn%2ByfzkhP0%3D&
> amp;reserved=0> Improve AutoFDO count propagation 
> algorithm %2F%2Fgcc.gnu.org%2Fgit%2F%3Fp%3Dgcc.git%3Ba%3Dcommit%3Bh%3D3d9e676793
> 9e9658260e2506e81ec32b37cba041&data=05%7C01%7CEugene.Rozenfeld%40m
> icrosoft.com%7Ccabaec504f234632a03a08da6f5780d2%7C72f988bf86f141

RE: [EXTERNAL] Re: State of AutoFDO in GCC

[Eugene Rozenfeld via Gcc]

Hi Jan,

Thank you for your reply. I did have you on the TO line in my latest patch:
https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596065.html

That's the patch I need a review on.

I'm looking forward to co-maintaining AutoFDO with you.

Thanks,

Eugene

-Original Message-
From: Jan Hubicka  
Sent: Wednesday, July 27, 2022 12:27 AM
To: David Edelsohn 
Cc: Eugene Rozenfeld ; Martin Liska 
; Xinliang David Li ; gcc 
; Andi Kleen ; Joseph Myers 

Subject: [EXTERNAL] Re: State of AutoFDO in GCC

> On Tue, Jul 26, 2022 at 4:13 PM Eugene Rozenfeld via Gcc 
>  wrote:
> >
> > Hello GCC community.
> >
> > I started this thread on the state of AutoFDO in GCC more than a 
> > year ago. Here is the first message in the thread: 
> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgc
> > c.gnu.org%2Fpipermail%2Fgcc%2F2021-April%2F235860.html&data=05%7
> > C01%7CEugene.Rozenfeld%40microsoft.com%7Cfe5184091a18487fd92d08da6fa
> > 1619e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63794503618637077
> > 0%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi
> > I6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=9%2Bnv2ShWxKh88K%
> > 2BsOeqPgQX3lOCJQ0lnF%2F7SUs4K4uI%3D&reserved=0
> >
> > Since then I committed a number of patches to revive AutoFDO in GCC:
> >
> > Fix a typo in an AutoFDO error 
> > string > 2F%2Fgcc.gnu.org%2Fgit%2F%3Fp%3Dgcc.git%3Ba%3Dcommit%3Bh%3D23691ddd3
> > aa3ffe55892b2bff54f9a15a89de2b4&data=05%7C01%7CEugene.Rozenfeld%
> > 40microsoft.com%7Cfe5184091a18487fd92d08da6fa1619e%7C72f988bf86f141a
> > f91ab2d7cd011db47%7C1%7C0%7C637945036186370770%7CUnknown%7CTWFpbGZsb
> > 3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> > D%7C3000%7C%7C%7C&sdata=qkecfE9uH5gy91vILQQlCk9RpExqPZxO4q02wiN1
> > EFw%3D&reserved=0> Update gen_autofdo_event.py and 
> > gcc-auto-profile. > l=https%3A%2F%2Fgcc.gnu.org%2Fgit%2F%3Fp%3Dgcc.git%3Ba%3Dcommit%3Bh%
> > 3D01d402c5e0ac1ddf5618bbe316b50067625fda46&data=05%7C01%7CEugene
> > .Rozenfeld%40microsoft.com%7Cfe5184091a18487fd92d08da6fa1619e%7C72f9
> > 88bf86f141af91ab2d7cd011db47%7C1%7C0%7C637945036186370770%7CUnknown%
> > 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC
> > JXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=E52qVFlfdfFGnW9yDsBNhh4k2ey8g
> > 3aJEGzH40MuSOc%3D&reserved=0> Fixes for AutoFDO 
> > tests > F%2Fgcc.gnu.org%2Fgit%2F%3Fp%3Dgcc.git%3Ba%3Dcommit%3Bh%3Df9ad3d5339
> > faaaed6e15a7b27d90fbc66eb72f37&data=05%7C01%7CEugene.Rozenfeld%4
> > 0microsoft.com%7Cfe5184091a18487fd92d08da6fa1619e%7C72f988bf86f141af
> > 91ab2d7cd011db47%7C1%7C0%7C637945036186370770%7CUnknown%7CTWFpbGZsb3
> > d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
> > %7C3000%7C%7C%7C&sdata=XYlFoY3OTTXHp18O1v8BY47A17NyNPXvUWWYsVnbD
> > 0U%3D&reserved=0> Fix indir-call-prof-2.c with 
> > AutoFDO > %2F%2Fgcc.gnu.org%2Fgit%2F%3Fp%3Dgcc.git%3Ba%3Dcommit%3Bh%3D0ed093c7
> > c3f755bc1cd80e5186abeb2f5c50ee0c&data=05%7C01%7CEugene.Rozenfeld
> > %40microsoft.com%7Cfe5184091a18487fd92d08da6fa1619e%7C72f988bf86f141
> > af91ab2d7cd011db47%7C1%7C0%7C637945036186370770%7CUnknown%7CTWFpbGZs
> > b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%
> > 3D%7C3000%7C%7C%7C&sdata=sLftY6hjvzSuE9ZgkGmXZLDpRMjlDo%2FEAyDyP
> > CviY5Q%3D&reserved=0> Fixes for AutoFDO 
> > testing > %2F%2Fgcc.gnu.org%2Fgit%2F%3Fp%3Dgcc.git%3Ba%3Dcommit%3Bh%3D9265b378
> > 531391498ec1727f67a45da72a6c07e9&data=05%7C01%7CEugene.Rozenfeld
> > %40microsoft.com%7Cfe5184091a18487fd92d08da6fa1619e%7C72f988bf86f141
> > af91ab2d7cd011db47%7C1%7C0%7C637945036186370770%7CUnknown%7CTWFpbGZs
> > b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%
> > 3D%7C3000%7C%7C%7C&sdata=lXZ%2F%2FbcfYD%2BQyIiXMAaCxOujEAfDXSY1p
> > 78kUb2md7w%3D&reserved=0> Fix indirect call inlining with 
> > AutoFDO > %2F%2Fgcc.gnu.org%2Fgit%2F%3Fp%3Dgcc.git%3Ba%3Dcommit%3Bh%3D285aa689
> > 5d479bed8e72ad363290846645b6faa0&data=05%7C01%7CEugene.Rozenfeld
> > %40microsoft.com%7Cfe5184091a18487fd92d08da6fa1619e%7C72f988bf86f141
> > af91ab2d7cd011db47%7C1%7C0%7C637945036186370770%7CUnknown%7CTWFpbGZs
> > b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%
> > 3D%7C3000%7C%7C%7C&sdata=ypoF%2BZnEe3eC3Gat6%2FjUJLV2XiltdjJHe68
> > pue64fSU%3D&reserved=0> Improve AutoFDO count propagation 
> > algorithm > 3A%2F%2Fgcc.gnu.org%2Fgit%2F%3Fp%3Dgcc.git%3Ba%3Dcommit%3Bh%3D3d9e67
> > 67939e9658260e2506e81ec32b37cba041&data=05%7C01%7CEugene.Rozenfe
> > ld%40microsoft.com%7Cfe5184091a18487fd92d08da6fa1619e%7C72f988bf86f1
> > 41af91ab2d7cd011db

RE: [EXTERNAL] Re: State of AutoFDO in GCC

[Eugene Rozenfeld via Gcc]

Hi Xionghu,

Yes, I'm pretty sure both of the fixes you mentioned are applicable to GCC 10. 
I'm not sure what the bar is for backporting fixes.
Jan, can you comment on that?
The fixes that Xionghu mentioned are:

Fix indirect call inlining with AutoFDO

https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=285aa6895d479bed8e72ad363290846645b6faa0
AutoFDO: Don't try to promote indirect calls that result in recursive 
direct calls

https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=ba125745d9e9fe90a18a2af8701b3269c5fdd468

Thanks,

Eugene

-Original Message-
From: Xionghu Luo  
Sent: Tuesday, July 26, 2022 6:41 PM
To: Eugene Rozenfeld ; Andi Kleen 
; Joseph Myers ; Jan Hubicka 
; gcc 
Subject: [EXTERNAL] Re: State of AutoFDO in GCC

[You don't often get email from yinyuefen...@gmail.com. Learn why this is 
important at https://aka.ms/LearnAboutSenderIdentification ]

On 2022/7/27 09:31, Xionghu Luo wrote:
>
>
> On 2022/7/27 04:12, Eugene Rozenfeld via Gcc wrote:
>> Hello GCC community.
>>
>> I started this thread on the state of AutoFDO in GCC more than a year 
>> ago. Here is the first message in the thread:
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc
>> .gnu.org%2Fpipermail%2Fgcc%2F2021-April%2F235860.html&data=05%7C0
>> 1%7CEugene.Rozenfeld%40microsoft.com%7Ccda1f6374c584732950e08da6f7126
>> 83%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637944829019804556%7C
>> Unknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1
>> haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=t%2B94vOYKb8SDZ9i86Fnin
>> iYXt7LTGXqbrbftH1TVqEs%3D&reserved=0
>>
>> Since then I committed a number of patches to revive AutoFDO in GCC:
>>
>> Fix a typo in an AutoFDO error
>> string> F%2Fgcc.gnu.org%2Fgit%2F%3Fp%3Dgcc.git%3Ba%3Dcommit%3Bh%3D23691ddd3aa
>> 3ffe55892b2bff54f9a15a89de2b4&data=05%7C01%7CEugene.Rozenfeld%40m
>> icrosoft.com%7Ccda1f6374c584732950e08da6f712683%7C72f988bf86f141af91a
>> b2d7cd011db47%7C1%7C0%7C637944829019804556%7CUnknown%7CTWFpbGZsb3d8ey
>> JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C30
>> 00%7C%7C%7C&sdata=4WD%2FgKxeXEFz7V6pcqDsYxvAbSOP3ldxXHb%2FoMxV5kc
>> %3D&reserved=0>
>>
>> Update gen_autofdo_event.py and
>> gcc-auto-profile.> =https%3A%2F%2Fgcc.gnu.org%2Fgit%2F%3Fp%3Dgcc.git%3Ba%3Dcommit%3Bh%3D
>> 01d402c5e0ac1ddf5618bbe316b50067625fda46&data=05%7C01%7CEugene.Ro
>> zenfeld%40microsoft.com%7Ccda1f6374c584732950e08da6f712683%7C72f988bf
>> 86f141af91ab2d7cd011db47%7C1%7C0%7C637944829019804556%7CUnknown%7CTWF
>> pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
>> Mn0%3D%7C3000%7C%7C%7C&sdata=TA%2FhV%2FKsRF3MUZmUL%2FpTWbESdx03VK
>> PIudXrrBjAMvQ%3D&reserved=0>
>>
>> Fixes for AutoFDO
>> tests> %2Fgcc.gnu.org%2Fgit%2F%3Fp%3Dgcc.git%3Ba%3Dcommit%3Bh%3Df9ad3d5339fa
>> aaed6e15a7b27d90fbc66eb72f37&data=05%7C01%7CEugene.Rozenfeld%40mi
>> crosoft.com%7Ccda1f6374c584732950e08da6f712683%7C72f988bf86f141af91ab
>> 2d7cd011db47%7C1%7C0%7C637944829019804556%7CUnknown%7CTWFpbGZsb3d8eyJ
>> WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300
>> 0%7C%7C%7C&sdata=AvWCTytUxlcXq%2BpjkWJmhkmV0nH%2Fn0CzC4alU9XA9%2F
>> 4%3D&reserved=0>
>>
>> Fix indir-call-prof-2.c with
>> AutoFDO> 2F%2Fgcc.gnu.org%2Fgit%2F%3Fp%3Dgcc.git%3Ba%3Dcommit%3Bh%3D0ed093c7c3
>> f755bc1cd80e5186abeb2f5c50ee0c&data=05%7C01%7CEugene.Rozenfeld%40
>> microsoft.com%7Ccda1f6374c584732950e08da6f712683%7C72f988bf86f141af91
>> ab2d7cd011db47%7C1%7C0%7C637944829019804556%7CUnknown%7CTWFpbGZsb3d8e
>> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3
>> 000%7C%7C%7C&sdata=3dlTtTfe4XOOm6BEy5YLWG0l3WlQdfbCyFiXs3Q7W1I%3D
>> &reserved=0>
>>
>> Fixes for AutoFDO
>> testing> 2F%2Fgcc.gnu.org%2Fgit%2F%3Fp%3Dgcc.git%3Ba%3Dcommit%3Bh%3D9265b37853
>> 1391498ec1727f67a45da72a6c07e9&data=05%7C01%7CEugene.Rozenfeld%40
>> microsoft.com%7Ccda1f6374c584732950e08da6f712683%7C72f988bf86f141af91
>> ab2d7cd011db47%7C1%7C0%7C637944829019804556%7CUnknown%7CTWFpbGZsb3d8e
>> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3
>> 000%7C%7C%7C&sdata=ZWSIQ0jb6t2DZQpDb%2F7e5FqKM6KKskM%2FAYzLpxbUkp
>> 4%3D&reserved=0>
>>
>> Fix indirect call inlining with
>> AutoFDO> 2F%2Fgcc.gnu.org%2Fgit%2F%3Fp%3Dgcc.git%3Ba%3Dcommit%3Bh%3D285aa6895d
>> 479bed8e72ad363290846645b6faa0&data=05%7C01%7CEugene.Rozenfeld%40
>> microsoft.com%7Ccda1f6374c584732950e08da6f712683%7C72f988bf86f141af91
>> ab2d7cd011db47%7C1%7C0%7C637944829019804556%7CUnknown%7CTWFpbGZsb3d8e
>> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3
>> 000%7C%7C%7C&sdata=W8kTuSjC188BYd3fkZvCK5UxWrY