Re: Making *-netbsd-* to mean ELF not a.out for all CPUs

[Nick Clifton via Gcc]

Hi John,


But they did offer some tentative support for my second suggestion of changing the meaning of bare 
"netbsd" --- "netbsdaout" would still be available to unambiguously request 
a.out for anyone that wants it.


I think that this would be OK for the binutils, providing that when configuring 
for
just "netbsd" there was a prominentant message in the config log saying 
something like:
"netbsd format now treated as ELF based.  Use netbsdaout if you want a.out format 
files".
(Probably with slightly better wording than that).

Cheers
  Nick

Re: [PATCH 1/2] libstdc++: Count pretty-printed tuple elements from 0 not 1

[Jonathan Wakely via Gcc]

Patches need go to gcc-patches@ not gcc@ (and libstdc++ patches need
to be CC'd to libstdc++@ as well).

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

[Wei Mi via Gcc]

Yeah, create_llvm_prof depends on llvm_symbolizer which shouldn't have the
same limitation. To separate from llvm, create_gcov still depends on the
old set of addr2line library which likely doesn't support dwarf v5. That is
an issue indeed.

Thanks,
Wei.

On Fri, Jun 11, 2021 at 6:14 PM Eugene Rozenfeld <
eugene.rozenf...@microsoft.com> wrote:

> It appears that create_gcov doesn't support binaries with dwarf version 5
> (which is the current default).
> I tried a trivial example and got reasonable gcov files for binaries with
> dwarf v2, v3, and v4 but the same example with dwarf v5 produced
> "File './sort' has mangled .debug_info section."
> and a gcov file with 0 functions.
>
> Does create_llvm_prof has the same limitation?
>
> Eugene
>
> -Original Message-
> From: Wei Mi 
> Sent: Wednesday, May 26, 2021 7:52 PM
> To: Eugene Rozenfeld 
> Cc: Andi Kleen ; Hongtao Yu ; Xinliang
> David Li ; Jan Hubicka ;
> gcc@gcc.gnu.org; Wenlei He 
> Subject: Re: [EXTERNAL] Re: State of AutoFDO in GCC
>
> Thanks. Good to know the build works with newer protobuf.
>
> Wei.
>
> On Wed, May 26, 2021 at 4:40 PM Eugene Rozenfeld <
> eugene.rozenf...@microsoft.com> wrote:
> >
> > 3.0.0 is the latest supported version on Ubuntu 18.04. I verified that
> the build works on Ubuntu 20.04 with  protobuf-compiler and libprotobuf-dev
> version 3.6.1.3.
> >
> > Eugene
> >
> > -Original Message-
> > From: Wei Mi 
> > Sent: Tuesday, May 25, 2021 8:07 PM
> > To: Eugene Rozenfeld 
> > Cc: Andi Kleen ; Hongtao Yu ; Xinliang
> > David Li ; Jan Hubicka ;
> > gcc@gcc.gnu.org; Wenlei He 
> > Subject: Re: [EXTERNAL] Re: State of AutoFDO in GCC
> >
> > I checked the source of protobuf 3.0.0 and it didn't contain the
> operator[] in RepeatedField. Need to install a newer version of protobuf.
> >
> > Thanks,
> > Wei.
> >
> > On Tue, May 25, 2021 at 1:49 PM Eugene Rozenfeld <
> eugene.rozenf...@microsoft.com> wrote:
> > >
> > > Both are 3.0.0-9.1ubuntu1:
> > >
> > > eugene@eugene-Virtual-Machine:~/autofdo1/build$ apt list
> > > protobuf-compiler Listing... Done protobuf-compiler/bionic,now
> > > 3.0.0-9.1ubuntu1 amd64 [installed]
> > > eugene@eugene-Virtual-Machine:~/autofdo1/build$ apt list
> > > libprotobuf-dev Listing... Done libprotobuf-dev/bionic,now
> > > 3.0.0-9.1ubuntu1 amd64 [installed]
> > >
> > > -Original Message-
> > > From: Wei Mi 
> > > Sent: Tuesday, May 25, 2021 9:17 AM
> > > To: Eugene Rozenfeld 
> > > Cc: Andi Kleen ; Hongtao Yu ;
> > > Xinliang David Li ; Jan Hubicka
> > > ; gcc@gcc.gnu.org; Wenlei He 
> > > Subject: Re: [EXTERNAL] Re: State of AutoFDO in GCC
> > >
> > > It looks like some version problem about protobuf-compiler and
> libprotobuf-dev. Could you check what is the installed version on your end
> for those two packages and see if they are consistent?
> > >
> > > On my platform, they are both 3.12.4.
> > >
> > > On Tue, May 25, 2021 at 12:01 AM Eugene Rozenfeld <
> eugene.rozenf...@microsoft.com> wrote:
> > > >
> > > > That eliminates the previous error but there is a new one:
> > > >
> > > > eugene@eugene-Virtual-Machine:~/autofdo1/build$ ninja [3/199]
> > > > Building CXX object
> > > > CMakeFiles/quipper_perf.dir/third_party/perf_data_converter/src/qu
> > > > ip
> > > > pe
> > > > r/perf_reader.cc.o
> > > > FAILED:
> CMakeFiles/quipper_perf.dir/third_party/perf_data_converter/src/quipper/perf_reader.cc.o
> > > > /usr/bin/c++   -I../third_party/perf_data_converter/src
> -I../third_party/perf_data_converter/src/quipper -I../
> -I../third_party/glog/src -I../third_party/abseil -I../util -I.
> -Ithird_party/glog -std=gnu++1z -MD -MT
> CMakeFiles/quipper_perf.dir/third_party/perf_data_converter/src/quipper/perf_reader.cc.o
> -MF
> CMakeFiles/quipper_perf.dir/third_party/perf_data_converter/src/quipper/perf_reader.cc.o.d
> -o
> CMakeFiles/quipper_perf.dir/third_party/perf_data_converter/src/quipper/perf_reader.cc.o
> -c ../third_party/perf_data_converter/src/quipper/perf_reader.cc
> > > > ../third_party/perf_data_converter/src/quipper/perf_reader.cc: In
> member function 'bool
> quipper::PerfReader::ReadCPUTopologyMetadata(quipper::DataReader*, size_t)':
> > > >
> ../third_party/perf_data_converter/src/quipper/perf_reader.cc:1518:46:
> error: no match for 'operator[]' (operand types are 'const
> google::protobuf::RepeatedField' and 'int')
> > > >  nrcpus = proto_uint32_metadata.data()[0];
> > > >
> > > > -Original Message-
> > > > From: Wei Mi 
> > > > Sent: Monday, May 24, 2021 8:54 PM
> > > > To: Eugene Rozenfeld 
> > > > Cc: Andi Kleen ; Hongtao Yu ;
> > > > Xinliang David Li ; Jan Hubicka
> > > > ; gcc@gcc.gnu.org; Wenlei He 
> > > > Subject: Re: [EXTERNAL] Re: State of AutoFDO in GCC
> > > >
> > > > It isn't exposed on my platform either. Looks like a bug in
> perf_data_converter (i.e., quipper). Could you try adding #include
>  in
> third_party/perf_data_converter/src/quipper/huge_page_deducer.cc and see if
> it fixes the problem? If it works, I will need to file a bug agai

Re: replacing the backwards threader and more

[Jeff Law via Gcc]

On 6/14/2021 12:40 AM, Richard Biener wrote:



I bet it's going to be tougher to remove DOM's threader.  It knows how
to do thinks like resolve memory references using temporary equivalences
and such.  But I bet it's enough to drop the VRP based threaders.

Yes.  In fact I am wondering if adding threading to the not iterating FRE
would make it possible to drop DOM, replacing it with instances of FRE.

I'd think so.  I'd approach as:

1. Remove the VRP threader instances.
2. Drop cprop and redundancy elimination from DOM using FRE instead
3. What's left of DOM is just forward jump threading.  Revamp & 
simplify.  Then either make it a distinct pass or as a sub-pass of FRE.


But one could just as easily look at adding threading to FRE and just 
killing DOM and its jump threading.


Jeff

Re: replacing the backwards threader and more

[Aldy Hernandez via Gcc]

On 6/15/21 6:03 AM, Jeff Law wrote:



On 6/14/2021 12:40 AM, Richard Biener wrote:



I bet it's going to be tougher to remove DOM's threader.  It knows how
to do thinks like resolve memory references using temporary equivalences
and such.  But I bet it's enough to drop the VRP based threaders.

Yes.  In fact I am wondering if adding threading to the not iterating FRE
would make it possible to drop DOM, replacing it with instances of FRE.

I'd think so.  I'd approach as:

1. Remove the VRP threader instances.
2. Drop cprop and redundancy elimination from DOM using FRE instead
3. What's left of DOM is just forward jump threading.  Revamp & 
simplify.  Then either make it a distinct pass or as a sub-pass of FRE.


But one could just as easily look at adding threading to FRE and just 
killing DOM and its jump threading.


Andrew will hopefully be contributing the relational work this week. 
Once he does so, I will gather more granular stats for VRP1/VRP2 so we 
can assess the situation.


Also, a bunch of tests needed to be tweaked because the new code picks 
up so many threads.  I'm waiting for the relational work to avoid having 
to adjust the tests again.


I would personally prefer to add an item 0 to the above list: replace 
current backwards threader code with the rewrite.  I would hate to 
replace all threaders at once and deal with the fallout.  Perhaps it's 
better to replace the backward threaders, and once that settles move 
onto VRP[12]??


Aldy