Question about function splitting

[Hanke Zhang via Gcc]

Hi, I have some questions about the strategy and behavior of function
splitting in gcc, like the following code:

int glob;
void f() {
  if (glob) {
printf("short path\n");
return;
  }
  // do lots of expensive things
  // ...
}

I hope it can be broken down like below, so that the whole function
can perhaps be inlined, which is more efficient.

int glob;
void f() {
  if (glob) {
printf("short path\n");
return;
  }
  f_part();
}

void f_part() {
  // do lots of expensive things
  // ...
}


But on the contrary, gcc splits it like these, which not only does not
bring any benefits, but may increase the time consumption, because the
function call itself is a more resource-intensive thing.

int glob;
void f() {
  if (glob) {
f_part();
return;
  }
  // do lots of expensive things
  // ...
}

void f_part() {
  printf("short path\n"); // just do this
}

Are there any options I can offer to gcc to change this behavior? Or
do I need to make some changes in ipa-split.cc?

Re: Question about function splitting

[Martin Jambor]

Hello,

On Mon, Oct 02 2023, Hanke Zhang via Gcc wrote:
> Hi, I have some questions about the strategy and behavior of function
> splitting in gcc, like the following code:
>
> int glob;
> void f() {
>   if (glob) {
> printf("short path\n");
> return;
>   }
>   // do lots of expensive things
>   // ...
> }
>
> I hope it can be broken down like below, so that the whole function
> can perhaps be inlined, which is more efficient.
>
> int glob;
> void f() {
>   if (glob) {
> printf("short path\n");
> return;
>   }
>   f_part();
> }
>
> void f_part() {
>   // do lots of expensive things
>   // ...
> }
>
>
> But on the contrary, gcc splits it like these, which not only does not
> bring any benefits, but may increase the time consumption, because the
> function call itself is a more resource-intensive thing.
>
> int glob;
> void f() {
>   if (glob) {
> f_part();
> return;
>   }
>   // do lots of expensive things
>   // ...
> }
>
> void f_part() {
>   printf("short path\n"); // just do this
> }
>
> Are there any options I can offer to gcc to change this behavior? Or
> do I need to make some changes in ipa-split.cc?

I'd suggest you file a bug to Bugzilla with a specific example that is
mis-handled, then we can have a look and discuss what and why happens
and what can be done about it.

Thanks,

Martin

Re: [PATCH] Fix coroutine tests for libstdc++ gnu-version-namespace mode

[François Dumont via Gcc]

Hi

Gentle reminder for this minor patch.

Thanks

On 23/09/2023 22:10, François Dumont wrote:
I'm eventually fixing those tests the same way we manage this problem 
in libstdc++ testsuite.


   testsuite: Add optional libstdc++ version namespace in expected 
diagnostic


    When libstdc++ is build with 
--enable-symvers=gnu-versioned-namespace diagnostics are

    showing this namespace, currently __8.

    gcc/testsuite/ChangeLog:

    * 
testsuite/g++.dg/coroutines/coro-bad-alloc-00-bad-op-new.C: Add optional

    '__8' version namespace in expected diagnostic.
    * 
testsuite/g++.dg/coroutines/coro-bad-alloc-01-bad-op-del.C: Likewise.
    * 
testsuite/g++.dg/coroutines/coro-bad-alloc-02-no-op-new-nt.C: Likewise.
    * 
testsuite/g++.dg/coroutines/coro-bad-grooaf-01-grooaf-expected.C: 
Likewise.

    * testsuite/g++.dg/coroutines/pr97438.C: Likewise.
    * testsuite/g++.dg/coroutines/ramp-return-b.C: Likewise.

Tested under Linux x86_64.

I'm contributing to libstdc++ so I already have write access.

Ok to commit ?

François

Re: Question about function splitting

[Hanke Zhang via Gcc]

Martin Jambor  于2023年10月3日周二 00:34写道：
>
> Hello,
>
> On Mon, Oct 02 2023, Hanke Zhang via Gcc wrote:
> > Hi, I have some questions about the strategy and behavior of function
> > splitting in gcc, like the following code:
> >
> > int glob;
> > void f() {
> >   if (glob) {
> > printf("short path\n");
> > return;
> >   }
> >   // do lots of expensive things
> >   // ...
> > }
> >
> > I hope it can be broken down like below, so that the whole function
> > can perhaps be inlined, which is more efficient.
> >
> > int glob;
> > void f() {
> >   if (glob) {
> > printf("short path\n");
> > return;
> >   }
> >   f_part();
> > }
> >
> > void f_part() {
> >   // do lots of expensive things
> >   // ...
> > }
> >
> >
> > But on the contrary, gcc splits it like these, which not only does not
> > bring any benefits, but may increase the time consumption, because the
> > function call itself is a more resource-intensive thing.
> >
> > int glob;
> > void f() {
> >   if (glob) {
> > f_part();
> > return;
> >   }
> >   // do lots of expensive things
> >   // ...
> > }
> >
> > void f_part() {
> >   printf("short path\n"); // just do this
> > }
> >
> > Are there any options I can offer to gcc to change this behavior? Or
> > do I need to make some changes in ipa-split.cc?
>
> I'd suggest you file a bug to Bugzilla with a specific example that is
> mis-handled, then we can have a look and discuss what and why happens
> and what can be done about it.
>
> Thanks,
>
> Martin

Hi, thanks for your reply.

I'm trying to create an account right now. And I put a copy of the
example code here in case someone is interested.

And I'm using gcc 12.3.0. When you complie the code below via 'gcc
test.c -O3 -flto -fdump-tree-fnsplit', you will find a phenomenon that
is consistent with what I described above in the gimple which is
dumped from fnsplit.

#include 
#include 

int opstatus;
unsigned char *objcode = 0;
unsigned long position = 0;
char *globalfile;

int test_split_write(char *file) {
  FILE *fhd;

  if (!opstatus) {
// short path here
printf("Object code generation not active! Forgot to call "
   "quantum_objcode_start?\n");
return 1;
  }

  if (!file)
file = globalfile;

  fhd = fopen(file, "w");

  if (fhd == 0)
return -1;

  fwrite(objcode, position, 1, fhd);

  fclose(fhd);

  int *arr = malloc(1000);
  for (int i = 0; i < 1000; i++) {
arr[i] = rand();
  }

  return 0;
}

// to avoid `test_split_write` inlining into main
void __attribute__((noinline)) call() { test_split_write("./txt"); }

int main() {
  opstatus = rand();
  objcode = malloc(100);
  position = 0;
  call();
  return 0;
}

RISC-V V C Intrinsic API v1.0 release meeting reminder (October 3rd, 2023)

[Eop Chen via Gcc]

Hi all,

A reminder that the next open meeting to discuss on the RISC-V V C Intrinsic 
API v1.0 is going to
be held on 2023/10/03 7AM (GMT -7) / 10PM (GMT +8).

The agenda can be found in the second page of the meeting slides (link 
).
Please join the calendar to be constantly notified - Google calender link 
,
 ICal 

We also have a mailing list now hosted by RISC-V International (link 
).

Regards,

eop Chen