From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1631 invoked by alias); 19 Dec 2014 11:11:44 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 1622 invoked by uid 89); 19 Dec 2014 11:11:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ob0-f177.google.com Received: from mail-ob0-f177.google.com (HELO mail-ob0-f177.google.com) (209.85.214.177) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 19 Dec 2014 11:11:42 +0000 Received: by mail-ob0-f177.google.com with SMTP id va2so11682828obc.8 for ; Fri, 19 Dec 2014 03:11:40 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.182.94.133 with SMTP id dc5mr4422652obb.32.1418987500104; Fri, 19 Dec 2014 03:11:40 -0800 (PST) Received: by 10.76.174.2 with HTTP; Fri, 19 Dec 2014 03:11:40 -0800 (PST) In-Reply-To: <549329C1.9050304@redhat.com> References: <53FD45A7.4000804@redhat.com> <53FF6840.9030505@redhat.com> <53FF6E61.6030507@redhat.com> <540755E5.7060602@redhat.com> <5409220E.6070100@redhat.com> <540E4337.70006@redhat.com> <5412438A.6030305@redhat.com> <54130E15.9030809@redhat.com> <549329C1.9050304@redhat.com> Date: Fri, 19 Dec 2014 11:20:00 -0000 Message-ID: Subject: Re: [debug-early] reuse variable DIEs and fix their context From: Richard Biener To: Aldy Hernandez Cc: Jason Merrill , gcc-patches , Jan Hubicka Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-12/txt/msg01637.txt.bz2 On Thu, Dec 18, 2014 at 8:23 PM, Aldy Hernandez wrote: > Hi Jason. > > It's embarrassing that I just got to this now. I hope you don't repay the > favor and take as long responding to me :(. > > On 09/12/14 08:15, Jason Merrill wrote: >> >> On 09/11/2014 08:51 PM, Aldy Hernandez wrote: > > >>> /* Generate hidden aliases for Java. */ >>> - if (candidates) >>> + if (java_hidden_aliases) >>> { >>> - build_java_method_aliases (candidates); >>> - delete candidates; >>> + build_java_method_aliases (java_hidden_aliases); >>> + delete java_hidden_aliases; >>> } >> >> >> Didn't it work to move this before finalize? I think the VTV stuff is >> all that really needs to come after it, and that can move out of the >> front end if this hook is a problem (which I don't really think it is). > > > I can't move the call to build_java_method_aliases until the compilation > proper has run because said function iterates through all the functions with > FOR_EACH_FUNCTION, and the set of available functions at parse time and > after the optimization passes are quite different, presumably because we've > pruned all the unused functions. > > If I move the call to build_java_method_aliases before the optimization > passes, we end up emitting many more hidden aliases which cause > handle_alias_pairs() in cgraphunit.c to bark with: > > error: 'void _ZGAN8__JArrayC4Ev()' aliased to external symbol > '_ZN8__JArrayC4Ev' > > So we either leave building Java method aliases after the optimization > passes, or we somehow tighten the candidate selection in > collect_candidates_for_java_method_aliases(): > > if (DECL_CLASS_SCOPE_P (fndecl) > && TYPE_FOR_JAVA (DECL_CONTEXT (fndecl)) > && TARGET_USE_LOCAL_THUNK_ALIAS_P (fndecl)) > > What do you suggest? Yeah, I've told you that this is a major blocker I couldn't resolve the last time I tried to move things. IMHO this Java method aliases needs to be made cgraph-aware somehow, thus we need to build the aliases as proper aliases during candidate collection but somehow mark them reclaimable by the cgraph code (builtding the aliases is only done if TREE_ASM_WRITTEN). Honza may have an idea here? Richard. > I can, however, move all the other non-VTV stuff to the parser in a > subsequent patch, while you respond to this query. > > Thanks. > Aldy