Re: "musttail" statement attribute for GCC?

[Alexander Monakov via Gcc]

On Fri, 23 Apr 2021, Josh Haberman via Gcc wrote:

> On Fri, Apr 23, 2021 at 1:10 PM Iain Sandoe  wrote:
> > I did try to use it this ^ for GCC coroutines (where such a guarantee is
> > pretty important)
> >
> > However, the issue there is that not all targets support indirect tailcalls.
> 
> I'm not familiar with this limitation. What targets do not support
> indirect tail calls?

On Power64 tailcalls to anything that is not a static function are tricky, and
current Clang ICEs for musttail indirect calls (or direct calls to a function
which is not static) on that target. GCC also doesn't do indirect tailcalls on
Power64.

Also, NVPTX (being an intermediate instruction set) does not define a "tailcall
instruction", so Clang also ICEs there. Just mentioning it for completeness.

> > What about tailcalls between DSOs?
> 
> What issues are there around DSOs? Clang/LLVM don't treat these
> specially AFAIK, and it seems that tail calls through a PLT should
> work okay?

No, some targets have additional requirements for calls that potentially go via
a (PIC) PLT. The most well-known example is probably 32-bit x86, which
requries the %ebx register to hold the address of GOT when entering a PLT
trampoline. Since %ebx is callee-saved, this makes tailcalling impossible.

LLVM solves this by transforming such calls to "no-plt" GOT-indirect calls under
'musttail', so evidently it does treat them specially.

Another example is mips64, where even non-PIC PLT is special (but looks like
LLVM does not do any tailcalls on mips64 at all).

Alexander

Re: "musttail" statement attribute for GCC?

[Iain Sandoe via Gcc]

Alexander Monakov  wrote:


On Fri, 23 Apr 2021, Josh Haberman via Gcc wrote:

On Fri, Apr 23, 2021 at 1:10 PM Iain Sandoe   
wrote:

I did try to use it this ^ for GCC coroutines (where such a guarantee is
pretty important)

However, the issue there is that not all targets support indirect  
tailcalls.


I'm not familiar with this limitation. What targets do not support
indirect tail calls?


On Power64 tailcalls to anything that is not a static function are  
tricky, and
current Clang ICEs for musttail indirect calls (or direct calls to a  
function
which is not static) on that target. GCC also doesn't do indirect  
tailcalls on

Power64.

Also, NVPTX (being an intermediate instruction set) does not define a  
"tailcall
instruction", so Clang also ICEs there. Just mentioning it for  
completeness.


Also aarch64-linux if I remember correctly.

One could use a trampoline to deal with the loading of additional state,  
but  I do
not want to go down that route for coroutines, if possible - since we  
already have
a state frame, it seems better to me to extend the ABI for that to include  
space

for target-specific data at a known offset from the frame pointer.

Iain




What about tailcalls between DSOs?


What issues are there around DSOs? Clang/LLVM don't treat these
specially AFAIK, and it seems that tail calls through a PLT should
work okay?


No, some targets have additional requirements for calls that potentially  
go via

a (PIC) PLT. The most well-known example is probably 32-bit x86, which
requries the %ebx register to hold the address of GOT when entering a PLT
trampoline. Since %ebx is callee-saved, this makes tailcalling impossible.

LLVM solves this by transforming such calls to "no-plt" GOT-indirect  
calls under

'musttail', so evidently it does treat them specially.

Another example is mips64, where even non-PIC PLT is special (but looks  
like

LLVM does not do any tailcalls on mips64 at all).

Alexander

Re: "musttail" statement attribute for GCC?

[Richard Earnshaw via Gcc]

On 26/04/2021 14:49, Iain Sandoe via Gcc wrote:

Alexander Monakov  wrote:


On Fri, 23 Apr 2021, Josh Haberman via Gcc wrote:

On Fri, Apr 23, 2021 at 1:10 PM Iain Sandoe  
wrote:
I did try to use it this ^ for GCC coroutines (where such a 
guarantee is

pretty important)

However, the issue there is that not all targets support indirect 
tailcalls.


I'm not familiar with this limitation. What targets do not support
indirect tail calls?


On Power64 tailcalls to anything that is not a static function are 
tricky, and
current Clang ICEs for musttail indirect calls (or direct calls to a 
function
which is not static) on that target. GCC also doesn't do indirect 
tailcalls on

Power64.

Also, NVPTX (being an intermediate instruction set) does not define a 
"tailcall
instruction", so Clang also ICEs there. Just mentioning it for 
completeness.


Also aarch64-linux if I remember correctly.


Tailcalling is possible on aarch64 using the normal branch instructions 
(B & BR).


There however be reasons why those can't be used in a specific 
compilation context.




One could use a trampoline to deal with the loading of additional state, 
but  I do
not want to go down that route for coroutines, if possible - since we 
already have
a state frame, it seems better to me to extend the ABI for that to 
include space

for target-specific data at a known offset from the frame pointer.

Iain




What about tailcalls between DSOs?


What issues are there around DSOs? Clang/LLVM don't treat these
specially AFAIK, and it seems that tail calls through a PLT should
work okay?


No, some targets have additional requirements for calls that 
potentially go via

a (PIC) PLT. The most well-known example is probably 32-bit x86, which
requries the %ebx register to hold the address of GOT when entering a PLT
trampoline. Since %ebx is callee-saved, this makes tailcalling 
impossible.


LLVM solves this by transforming such calls to "no-plt" GOT-indirect 
calls under

'musttail', so evidently it does treat them specially.

Another example is mips64, where even non-PIC PLT is special (but 
looks like

LLVM does not do any tailcalls on mips64 at all).

Alexander

Re: State of AutoFDO in GCC

[Andi Kleen via Gcc]

Jan Hubicka  writes:
>
> Is there a way to get this working w/o using older perf?

It's usually rather simple to fix up autofdo for new perf.
I did it before here

https://github.com/andikleen/autofdo/commits/perf4-3

I think it would work always if it just ignored unknown records
(which is quite possible). perf adds new records now and then,
but they can be usually ignored by old tools.
Only the assert happy coding style in autofdo prevents it.

BTW longer term my feeling is autofdo should be replaced with something
like https://lists.llvm.org/pipermail/llvm-dev/2020-August/144101.html
I think that would fix most of the weirdnesses in the current autofdo
implementation.

-Andi

Re: gcc-11-20210425 is now available

[Joseph Myers]

On Mon, 26 Apr 2021, Arseny Solokha via Gcc wrote:

> Hi,
> 
> > Snapshot gcc-11-20210425 is now available on
> >   https://gcc.gnu.org/pub/gcc/snapshots/11-20210425/
> > and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
> >
> > This snapshot has been generated from the GCC 11 git branch
> > with the following options: git://gcc.gnu.org/git/gcc.git branch master 
> > revision c54a9f7259fce1a221270f21d8076c960c7d0163
> 
> the snapshot has been really generated from the master branch and thus
> represents GCC 12, not 11.

Thanks, I've updated the GCC scripts checkout and crontab actually in use 
for generating snapshots and am running a fresh GCC 11 snapshot with diffs 
from 11-20210418.

-- 
Joseph S. Myers
jos...@codesourcery.com

gcc-11-20210426 is now available

[GCC Administrator via Gcc]

Snapshot gcc-11-20210426 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/11-20210426/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

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

You'll find:

 gcc-11-20210426.tar.xz   Complete GCC

  SHA256=b7eebc1d8f9adf5cd229dcc6842109e746d2f64daedaeef4403ba4942ae86afd
  SHA1=d28ac7fe66a4d14f27394e5e0c95bf2f09c0765e

Diffs from 11-20210418 are available in the diffs/ subdirectory.

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

gcc-12-20210426 is now available

[GCC Administrator via Gcc]

Snapshot gcc-12-20210426 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/12-20210426/
and on various mirrors, see http://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 master 
revision db3581c4ae4d44edea2b64347095d14363721668

You'll find:

 gcc-12-20210426.tar.xz   Complete GCC

  SHA256=3f7836620e30873a2c487f8081526b33c29ae7d2e2453022cbb7c3cec65ba7c7
  SHA1=cd2b729970a1f6ca1216a9a26cbb4b37ab61ba65

Diffs from 11-20210418 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.

Re: State of AutoFDO in GCC

[Xinliang David Li via Gcc]

On Mon, Apr 26, 2021 at 8:12 AM Andi Kleen  wrote:

> Jan Hubicka  writes:
> >
> > Is there a way to get this working w/o using older perf?
>
> It's usually rather simple to fix up autofdo for new perf.
> I did it before here
>
> https://github.com/andikleen/autofdo/commits/perf4-3
>
> I think it would work always if it just ignored unknown records
> (which is quite possible). perf adds new records now and then,
> but they can be usually ignored by old tools.
> Only the assert happy coding style in autofdo prevents it.
>
> BTW longer term my feeling is autofdo should be replaced with something
> like https://lists.llvm.org/pipermail/llvm-dev/2020-August/144101.html
> I think that would fix most of the weirdnesses in the current autofdo
> implementation.
>

There are multiple directional changes in this new tool:
1) it uses perf-script trace output (in text) as input profile data;
2) it uses pseudo probe like instrumentation FDO to do profile matching;
3) it supports full profile context sensitivity (not just from inline
stacks).

#1 is most relevant to this discussion -- using text format reduces the
pain introduced by perf binary format change.

David



>
> -Andi
>

[walter thierry]RE:Journée fantastique

[Machelle Ruyter via Gcc]

Je l'ai aimé❗ http://9w6ed2v.worknumbermethod.work/d10

walter thierry




loyalement

Re: State of AutoFDO in GCC

[Andi Kleen via Gcc]

>There are multiple directional changes in this new tool:
>1) it uses perf-script trace output (in text) as input profile data; 

I suspect this will break regularly too

(I personally did numerous changes to perf script output, and also
wrote a lot of parsing scripts)

The perf script output has some bad problems, e.g. for file names or processes
with spaces and some other issues. To make it handleable would need some
redesign to actually generate in a machine friendly format.

A perf.data parser should be fine, just don't fill it up with asserts
and "be liberal what you accept" and ignore unknown records.

-Andi

Re: State of AutoFDO in GCC

[Xinliang David Li via Gcc]

On Mon, Apr 26, 2021 at 11:00 AM Andi Kleen  wrote:

> >There are multiple directional changes in this new tool:
> >1) it uses perf-script trace output (in text) as input profile data;
>
> I suspect this will break regularly too
>
> (I personally did numerous changes to perf script output, and also
> wrote a lot of parsing scripts)
>
> The perf script output has some bad problems, e.g. for file names or
> processes
> with spaces and some other issues. To make it handleable would need some
> redesign to actually generate in a machine friendly format.
>

Andi, thanks for the input.


+authors of the llvm-profgen tool for their experience with using perf
script output.

David




>
> A perf.data parser should be fine, just don't fill it up with asserts
> and "be liberal what you accept" and ignore unknown records.
>
> -Andi
>

Re: State of AutoFDO in GCC

[Hongtao Yu via Gcc]

Andi, thanks for pointing out the perf script issues. Can you please elaborate 
a bit on the exact issue you have seen? We’ve been using specific output of 
perf script such as mmap, LBR and callstack events filtered by process id. It 
works fine so far but may certainly hit issues in the future with extended uses.

Thanks,
Hongtao

From: Xinliang David Li 
Date: Monday, April 26, 2021 at 11:05 AM
To: Andi Kleen 
Cc: Jan Hubicka , gcc@gcc.gnu.org , Wei Mi 
, Eugene Rozenfeld , Wenlei He 
, Hongtao Yu 
Subject: Re: State of AutoFDO in GCC


On Mon, Apr 26, 2021 at 11:00 AM Andi Kleen 
mailto:a...@linux.intel.com>> wrote:
>There are multiple directional changes in this new tool:
>1) it uses perf-script trace output (in text) as input profile data;

I suspect this will break regularly too

(I personally did numerous changes to perf script output, and also
wrote a lot of parsing scripts)

The perf script output has some bad problems, e.g. for file names or processes
with spaces and some other issues. To make it handleable would need some
redesign to actually generate in a machine friendly format.

Andi, thanks for the input.


+authors of the llvm-profgen tool for their experience with using perf script 
output.

David




A perf.data parser should be fine, just don't fill it up with asserts
and "be liberal what you accept" and ignore unknown records.

-Andi

Re: State of AutoFDO in GCC

[Andi Kleen via Gcc]

On Mon, Apr 26, 2021 at 06:40:56PM +, Hongtao Yu wrote:
>Andi, thanks for pointing out the perf script issues. Can you please
>elaborate a bit on the exact issue you have seen? We’ve been using
>specific output of perf script such as mmap, LBR and callstack events
>filtered by process id. It works fine so far but may certainly hit issues
>in the future with extended uses.

The main problem is that you cannot just split the output in fields because
some fields (like file names or process names) can have spaces without
any kind of delimeter.

It's possible to work around this, but tends to be fragile and ugly.

Also there were occasional changes in the output the past.

-Andi

Re: Has FSF stopped processing copyright paperwork

[Romain GEISSLER via Gcc]

Hi,

(Please note that this mail is *NOT* about the recent discussions about the
relationship with the FSF. AFAIK to date FSF copyright assignment is still
required to contribute to gcc and this request is solely about how to have one
signed.)

Few weeks later, I would like to know if anyone on the list knows if FSF is
still processing copyright assignment these days. Basically shall people
willing to sign one just have to be patient as processing is still on-going,
or if processing copyright assignment is fully frozen.

I do understand that both Covid 19 and the recent change of team/management
in FSF staff have impacted the copyright assignment processing time. However
right now it seems FSF does not reply anymore (at least to me) when asking
for status of papers submitted in late 2020. The last mail reply I had from
FSF (copyright-cl...@fsf.org) was in january. I had no answer when trying to
revive this private mail thread with FSF 2 weeks ago.

So anyone has some insider information about the FSF copright assignment
process ?

Cheers,
Romain

Re: Has FSF stopped processing copyright paperwork

[Andreas Schwab]

On Apr 26 2021, Romain GEISSLER via Gcc wrote:

> So anyone has some insider information about the FSF copright assignment
> process ?

I don't have insider information, but I just received a confirmation of
a copyright assignment for glibc.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Has FSF stopped processing copyright paperwork

[Paul Smith]

On Mon, 2021-04-26 at 21:01 +, Romain GEISSLER via Gcc wrote:
> So anyone has some insider information about the FSF copright
> assignment process ?

I have no insider information but you can try asking on
gnu-prog-disc...@gnu.org (I think that list is open)

I assume you're communicating with copyright-cl...@fsf.org ?

Re: Has FSF stopped processing copyright paperwork

[Gerald Pfeifer]

On Mon, 26 Apr 2021, Romain GEISSLER via Gcc wrote:
> Few weeks later, I would like to know if anyone on the list knows if FSF is
> still processing copyright assignment these days. Basically shall people
> willing to sign one just have to be patient as processing is still on-going,
> or if processing copyright assignment is fully frozen.

I got notified of copyright assignments related to GCC by 
copyright-cl...@fsf.org on April 5th, April 8th, April 22nd 
(two instances) and April 26th (today).

So the process seems to be operational.

Gerald

Re: Has FSF stopped processing copyright paperwork

[Romain GEISSLER via Gcc]

Le 26 avr. 2021 à 23:31, Gerald Pfeifer 
mailto:ger...@pfeifer.com>> a écrit :

I got notified of copyright assignments related to GCC by
copyright-cl...@fsf.org on April 5th, April 
8th, April 22nd
(two instances) and April 26th (today).

So the process seems to be operational.

Gerald

Ok thanks for confirming. So it means I need to be more patient then !
I will contact again copyright-cl...@fsf.org in 
a some weeks to try to have
news about my case.

Cheers,
Romain

SOOL Hashes

[Aaron Gray via Gcc]

a712557bc4d071895a30d5691395661c15d40f738e7090ea8ffc923e20d746ac2177374146a5699512a3a9f1d6e576ad4b070a78233d01ec9493f88e8564a198
 SOOL Presentation - in depth.pdf
532f84ce40ed291d7c00b3714904300c2bd538f836cb3bdf5b28003eb0c19ebdcf1f9faf0fabf8a3be6ecc6f7c29cfedd67464e467f98742445e0b2d555145d0
 SOOL Presentation - in depth.pptx
74294b176de8f4826e5881459de03c3f0f97da2896a5ab0075622baf4db68add8d8d580e6426523de3648cc9acdb89255142d3d473e5945ca2091915d91e71c9
 SOOL Presentation.pdf
7269bb7092991501f63631f548d4838bd8845645366bfd52fba452f3dbf470c3d0cd5194829b93789f74080884261eb9a6808aac7a98f73b0e0243cc0f1bd652
 SOOL Presentation.pptx

-- 
Aaron Gray

Independent Open Source Software Engineer, Computer Language
Researcher, Information Theorist, and Computer Scientist.