Re: [PATCH] Try LTO partial linking. (Was: Speed of compiling gimple-match.c)
Hi, all.
Please CC me when I am mentioned into a mail.
On Thu, 2021-05-20 at 15:16 +0200, Richard Biener via Gcc wrote:
> On Thu, May 20, 2021 at 3:06 PM Martin Liška wrote:
> >
> > On 5/20/21 2:54 PM, Richard Biener wrote:
> > > So why did you go from applying this per-file to multiple files?
> >
> > When I did per-file for {gimple,generic}-match.c I hit the
> > following issue with lto.priv symbols:
> >
> > /usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-
> > linux/bin/ld: error: libbackend.a(generic-match.o): multiple
> > definition of 'wi::to_wide(tree_node const*) [clone .part.0] [clone
> > .lto_priv.0]'
> > /usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-
> > linux/bin/ld: libbackend.a(gimple-match.o): previous definition
> > here
> > /usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-
> > linux/bin/ld: error: libbackend.a(generic-match.o): multiple
> > definition of 'TYPE_VECTOR_SUBPARTS(tree_node const*) [clone
> > .part.0] [clone .lto_priv.0]'
> > /usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-
> > linux/bin/ld: libbackend.a(gimple-match.o): previous definition
> > here
> > /usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-
> > linux/bin/ld: error: libbackend.a(generic-match.o): multiple
> > definition of 'vec > vl_embed>::operator[](unsigned int) [clone .part.0] [clone
> > .lto_priv.0]'
> >
> > Any idea what was I doing wrong?
>
> Nothing in particular I think - you're just hitting the issue that
> LTO
> produces new symbols and that those
> can obviously clash. Giuliano hit the very same issue. When not
> doing partial links those internal
> symbols pose no problem, but with -r -flinker-output=nolto-rel and
> re-linking the produced objects
> they obviously do. ELF has no solution for this though, but I think
> we could strip those from the
> partially linked object - if WPA would give us a list of objects the
> link step could postprocess
> the object with objcopy or maybe a custom linker script could do the
> trick as well.
I've "fixed" this issue in my branch by mangling any promoted to public
symbol. I've also disabled the "ipa-split" pass in the paper branch
because of some created symbols which I was not able to fix in time.
Perhaps this goes away if you disable it.
Perhaps we should work on getting the autopar branch merged into trunk.
There are several issues which must be fixed and I don't think it will
be ready for this next release. The main ones that I remember from the
top of my head:
1- Fix the driver to use SPEC language for the multiple required calls
to `as`, instead of injecting code for that directly on the `void
execute()` function.
2- Merge my custom partitioner for using the default LTO partitioner.
The default LTO partitioner were hitting the assertions about COMDAT
being split into multiple partitions.
3- Fix the issue with the ipa-split pass.
Perhaps we should further explore avoiding partial linking altogether
and concat the assembler files.
Thank you,
Giuliano.
>
> So your workaround is to only ever have a single LTO produced object
> file participating in the
> final links ;)
>
> Richard.
>
> >
> > Martin
gcc-11-20210612 is now available
Snapshot gcc-11-20210612 is now available on https://gcc.gnu.org/pub/gcc/snapshots/11-20210612/ 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 f9cc49ecebfa11f356c5c5ba550c9ac87a7231f6 You'll find: gcc-11-20210612.tar.xz Complete GCC SHA256=e180ef23cfdedaf33e095a27056e0bc32f8aaa30b600b01f1c23376d44e75f13 SHA1=f87e6699b92b8dbee7392e6ec92f944fd18d9603 Diffs from 11-20210605 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.
[no subject]
Sent from my Samsung Galaxy smartphone.
Re:
Sent from my MacBook Air
genmatch and cond vs "for (cnd cond vec_cond)" for gimple
Hi all, While moving the simple A CMP 0 ? A : -A patterns from fold_cond_expr_with_comparison to match, I ran into an issue where using cond directly in the patterns work while "for cnd (cond vec_cond)" don't work. It looks like in the first case we are able to correctly handle the cond first operand being a comparison while with the for loop we are not. That is the following additional pattern works: /* A == 0? A : -Asame as -A */ (simplify (cond (eq @0 zerop) @0 (negate@1 @0)) (if (!HONOR_SIGNED_ZEROS (element_mode (type))) @1)) (simplify (cond (eq @0 zerop) zerop (negate@1 @0)) (if (!HONOR_SIGNED_ZEROS (element_mode (type))) @1))) While this one does not work: (for cnd (cond vec_cond) /* A == 0? A : -Asame as -A */ (simplify (cnd (eq @0 zerop) @0 (negate@1 @0)) (if (!HONOR_SIGNED_ZEROS (element_mode (type))) @1)) (simplify (cnd (eq @0 zerop) zerop (negate@1 @0)) (if (!HONOR_SIGNED_ZEROS (element_mode (type))) @1))) CUT --- I will try to debug genmatch some but I wanted to get this email out to record what will need to be fixed to continue the movement of phiopt over to match. Thanks, Andrew Pinski
Re: genmatch and cond vs "for (cnd cond vec_cond)" for gimple
On Sat, Jun 12, 2021 at 4:54 PM Andrew Pinski wrote: > > Hi all, > While moving the simple A CMP 0 ? A : -A patterns from > fold_cond_expr_with_comparison to match, I ran into an issue where > using cond directly in the patterns work while "for cnd (cond > vec_cond)" don't work. > It looks like in the first case we are able to correctly handle the > cond first operand being a comparison while with the for loop we are > not. > > That is the following additional pattern works: > /* A == 0? A : -Asame as -A */ > (simplify > (cond (eq @0 zerop) @0 (negate@1 @0)) > (if (!HONOR_SIGNED_ZEROS (element_mode (type))) >@1)) > (simplify > (cond (eq @0 zerop) zerop (negate@1 @0)) > (if (!HONOR_SIGNED_ZEROS (element_mode (type))) >@1))) > > While this one does not work: > (for cnd (cond vec_cond) > /* A == 0? A : -Asame as -A */ > (simplify > (cnd (eq @0 zerop) @0 (negate@1 @0)) > (if (!HONOR_SIGNED_ZEROS (element_mode (type))) >@1)) > (simplify > (cnd (eq @0 zerop) zerop (negate@1 @0)) > (if (!HONOR_SIGNED_ZEROS (element_mode (type))) >@1))) > > CUT --- > I will try to debug genmatch some but I wanted to get this email out > to record what will need to be fixed to continue the movement of > phiopt over to match. So the problem is we lower for loops first and then cond. Though swapping the order in genmatch's lower function causes invalid C++ code to be generated :(. Still trying to figure out why though. Thanks, Andrew > > Thanks, > Andrew Pinski
Re: genmatch and cond vs "for (cnd cond vec_cond)" for gimple
On Sat, Jun 12, 2021 at 5:21 PM Andrew Pinski wrote: > > On Sat, Jun 12, 2021 at 4:54 PM Andrew Pinski wrote: > > > > Hi all, > > While moving the simple A CMP 0 ? A : -A patterns from > > fold_cond_expr_with_comparison to match, I ran into an issue where > > using cond directly in the patterns work while "for cnd (cond > > vec_cond)" don't work. > > It looks like in the first case we are able to correctly handle the > > cond first operand being a comparison while with the for loop we are > > not. > > > > That is the following additional pattern works: > > /* A == 0? A : -Asame as -A */ > > (simplify > > (cond (eq @0 zerop) @0 (negate@1 @0)) > > (if (!HONOR_SIGNED_ZEROS (element_mode (type))) > >@1)) > > (simplify > > (cond (eq @0 zerop) zerop (negate@1 @0)) > > (if (!HONOR_SIGNED_ZEROS (element_mode (type))) > >@1))) > > > > While this one does not work: > > (for cnd (cond vec_cond) > > /* A == 0? A : -Asame as -A */ > > (simplify > > (cnd (eq @0 zerop) @0 (negate@1 @0)) > > (if (!HONOR_SIGNED_ZEROS (element_mode (type))) > >@1)) > > (simplify > > (cnd (eq @0 zerop) zerop (negate@1 @0)) > > (if (!HONOR_SIGNED_ZEROS (element_mode (type))) > >@1))) > > > > CUT --- > > I will try to debug genmatch some but I wanted to get this email out > > to record what will need to be fixed to continue the movement of > > phiopt over to match. > > So the problem is we lower for loops first and then cond. Though > swapping the order in genmatch's lower function causes invalid C++ > code to be generated :(. > Still trying to figure out why though. I figured out why; lower_cond does not copy for_subst_vec for the new simplifier. Fixing that allows the switching of the order of the two lower functions which is needed in this case. I will submit the patch for this when I submit the patch set for converting the simple "A CMP 0 ? A : - A" of fold_cond_expr_with_comparison. Thanks, Andrew Pinski > > Thanks, > Andrew > > > > > Thanks, > > Andrew Pinski
Re: Lack of latest binutils in gcc 11 docker image
On Fri, Jun 11, 2021 at 4:39 AM Jonathan Wakely wrote: > > > I was wondering where can we send a patch to add binutils (latest ) > > to that docker hub image > > Those images are maintained by Docker Inc. and nothing to do with the > GCC project: > > https://docs.docker.com/docker-hub/official_images/ > > "All Official Images contain a User Feedback section in their > documentation which covers the details for that specific repository. > In most cases, the GitHub repository which contains the Dockerfiles > for an Official Repository also has an active issue tracker. General > feedback and support questions should be directed to #docker-library > on Freenode IRC." > Thanks a lot, i will contact the community and let them know Regards
