Re: Wrong date

2024-05-23 Thread Mark Wielaard
Hi Tony,

On Wed, May 22, 2024 at 06:58:34PM -0500, tony.antonucci--- via Gcc wrote:
> This was for the gcc 14.1 release.
> Sorry I omitted that in the first email.

Thanks for the notice, this has been fixed now:
https://gcc.gnu.org/cgit/gcc-wwwdocs/commit/?id=465817d0e0a96a1e1722a67383183dbec95ab21f

> > On May 22, 2024, at 6:57 PM, tony.antonu...@gmail.com wrote:
> > 
> > The date on the cool text graph of gcc releases is incorrect.
> > It says 2023, and should be 2024.
> > 
> > Tony


gcc-12-20240523 is now available

2024-05-23 Thread GCC Administrator via Gcc
Snapshot gcc-12-20240523 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/12-20240523/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 12 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-12 revision df191554a59364da04c169dd02e44368ca1811ca

You'll find:

 gcc-12-20240523.tar.xz   Complete GCC

  SHA256=06b12e36dfa8c5fd9ff0b727d4ca9d676c9fcced793e08bf001ce2ed15f07456
  SHA1=466bf7cd255d56ad87241704650b2ad30e660c10

Diffs from 12-20240516 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-12
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.


Question about optimizing function pointers for direct function calls

2024-05-23 Thread Hanke Zhang via Gcc
Hi,
I got a question about optimizing function pointers for direct
function calls in C.

Consider the following scenario: one of the fields of a structure is a
function pointer, and all its assignments come from the same function.
Can all its uses be replaced by direct calls to this function? So the
later passes can do more optimizations.

Here is the example:

int add(int a, int b) { return a + b; }
int sub(int a, int b) { return a - b; }

struct Foo {
int (*add)(int, int);
};
int main()
{
struct Foo foo[5] = malloc(sizeof(struct Foo) * 5);

for (int i = 0; i < 5; i++) {
foo[i].add = add;
}

int sum = 0;
for (int i = 0; i < 5; i++) {
sum += foo[i].add(1, 2);
}

return 0;
}

Can I replace the code above to the code below?

int add(int a, int b) { return a + b; }
int sub(int a, int b) { return a - b; }

struct Foo {
int (*add)(int, int);
};
int main()
{
struct Foo foo[5] = malloc(sizeof(struct Foo) * 5);

for (int i = 0; i < 5; i++) {
foo[i].add = add;
}

int sum = 0;
for (int i = 0; i < 5; i++) {
sum += add(1,2);
}

return 0;
}

My idea is to determine whether the assignment of the field is the
same function, and if so, perform the replacement.

Of course this is not a reasonable optimization, I just want to know
if there are security issues in doing so, and if I want to do it in
the IPA stage, is it possible?

Thanks
Hanke Zhang


Re: Question about optimizing function pointers for direct function calls

2024-05-23 Thread Richard Biener via Gcc
On Fri, May 24, 2024 at 5:53 AM Hanke Zhang via Gcc  wrote:
>
> Hi,
> I got a question about optimizing function pointers for direct
> function calls in C.
>
> Consider the following scenario: one of the fields of a structure is a
> function pointer, and all its assignments come from the same function.
> Can all its uses be replaced by direct calls to this function? So the
> later passes can do more optimizations.
>
> Here is the example:
>
> int add(int a, int b) { return a + b; }
> int sub(int a, int b) { return a - b; }
>
> struct Foo {
> int (*add)(int, int);
> };
> int main()
> {
> struct Foo foo[5] = malloc(sizeof(struct Foo) * 5);
>
> for (int i = 0; i < 5; i++) {
> foo[i].add = add;
> }
>
> int sum = 0;
> for (int i = 0; i < 5; i++) {
> sum += foo[i].add(1, 2);
> }
>
> return 0;
> }
>
> Can I replace the code above to the code below?
>
> int add(int a, int b) { return a + b; }
> int sub(int a, int b) { return a - b; }
>
> struct Foo {
> int (*add)(int, int);
> };
> int main()
> {
> struct Foo foo[5] = malloc(sizeof(struct Foo) * 5);
>
> for (int i = 0; i < 5; i++) {
> foo[i].add = add;
> }
>
> int sum = 0;
> for (int i = 0; i < 5; i++) {
> sum += add(1,2);
> }
>
> return 0;
> }
>
> My idea is to determine whether the assignment of the field is the
> same function, and if so, perform the replacement.

If it's as simple as above then sure, even CSE should do it.  If you
can prove otherwise the memory location with the function pointer
always has the same value you are obviously fine.  If you just
do not see any other store via 'add's FIELD_DECL then no, that
isn't good enough.  Every void * store you do not know where it
goes might go to that slot.

> Of course this is not a reasonable optimization, I just want to know
> if there are security issues in doing so, and if I want to do it in
> the IPA stage, is it possible?

For the more general case you can do what we do for speculative
devirtualization - replace the code with

  sum += foo[i].add == add ? add (1,2) : foo[i].add(1,2);

that way we can inline the direct call and hopefully the branch will be
well predicted.

In some SPEC there is IIRC the situation where such speculative
devirtualization candidates can be found solely based on function
signature.  With LTO/IPA you'd basically collect candidate targets
for each indirect call (possibly address-taken function definitions
with correct signature) and if there's just a single one you can
choose that as speculative devirt target.

Speculative devirt as we have now of course works with profile
data to identify the most probable candidate.

Richard.

>
> Thanks
> Hanke Zhang