C pre-processor: Better grammar for multi-line macros

[Yair Lenga via Gcc]

Hi,

I'm trying to get community feedback for a proposal to enhance the C
preprocessor support for multi-line macros.

For this discussion, I prefer to put aside the philosophical debate about
using macro vs generics - I'm assuming preprocessor macros are a valid
solution to implement generic logic (and other constructs) that are not
part of the "C" language.

Summary: When implementing long macro that can not be practical expressed
in a single line, one must use escaped new lines to implement the macros.
This result in hard to maintain code - it's not possible to move code
between regular functions, and macro functions. Also, it is hard to enter
comments, or format the code for readability, as each unescaped newline
will break macro definition.

Proposing: adding a new directive '#macro' which will define a multi-line
macro. The macro body will end with "#endmacro". (Similar to #if ...
#endif).

For example, a macro to count the number of elements that match a specific
condition, using statement expressions. This is a relatively simple
example, as there are macros that span > 30 (or more) lines in various
projects.

---
#macro count_if(array, length, item, condition)
   ({
  int count = 0 ;

  for (int i=0 ; i

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

[Surya Kumari Jangala via Gcc]

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.

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

[Eugene Rozenfeld via Gcc]

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.

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&data=04%7C01%7CEugene.Rozenfeld%40microsoft.com%7C9d79b87018f24bcbf8cc08d913d80bd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637562640903545786%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ts53XULDtR3o7fevlntCJdtzRqTo9R85LrxJ0ZfOBnE%3D&reserved=0
nor on
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgcc-mirror%2Fgcc&data=04%7C01%7CEugene.Rozenfeld%40microsoft.com%7C9d79b87018f24bcbf8cc08d913d80bd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637562640903545786%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2FPGF3vy3hD1OwiXmWzkUnOt9%2BR3YArZw0kCVueOKYpc%3D&reserved=0
but
git fetch origin vendors/google/heads/gcc-4_8 does the trick for fetching the 
commits, but not the symbolic branches.

Anyways with that it looks like the discriminator changes are:

commit fd9de90d750e3588b1e5a218b28102b6c8bb8434
Author: Dehao Chen mailto:de...@gcc.gnu.org>>
Date:   Thu Oct 10 14:39:31 2013 +

Use only lineno+discriminator (remove the callee function name) as the key 
to represent callsite. Because each callsite will have its discriminator if in 
the same line.

2013-10-10  Dehao Chen  

Re: State of AutoFDO in GCC

[David Edelsohn 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?

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&data=04%7C01%7CEugene.Rozenfeld%40microsoft.com%7C9d79b87018f24bcbf8cc08d913d80bd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637562640903545786%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ts53XULDtR3o7fevlntCJdtzRqTo9R85LrxJ0ZfOBnE%3D&reserved=0
> nor on
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgcc-mirror%2Fgcc&data=04%7C01%7CEugene.Rozenfeld%40microsoft.com%7

Re: State of AutoFDO in GCC

[Xionghu Luo via Gcc]

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://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


This "indirect call inlining with AutoFDO" patch need to be backported 
to at least gcc-10 as it will caused stack overflow for some cases I've 
met...


Xionghu

Indu Bhagat and David Faust appointed CTF and BTF Reviewers

[David Edelsohn via Gcc]

I am pleased to announce that the GCC Steering Committee has appointed
Indu Bhagat and David Faust as CTF and BTF Reviewers.

Please join me in congratulating Indu and David on their new role.

Indu and David, please update your listings in the MAINTAINERS file.

Happy hacking!
David

Re: State of AutoFDO in GCC

[Xionghu Luo via Gcc]

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://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 



This "indirect call inlining with AutoFDO" patch need to be backported 
to at least gcc-10 as it will caused stack overflow for some cases I've 
met...



Sorry, should be this:
 AutoFDO: Don't try to promote indirect calls that result in recursive 
direct 
calls,


Though the "indirect call inlining with AutoFDO" also need verify on old
branches.  indirect call format is updated with Martin's dynamic topn patch.



Xionghu