From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 113960 invoked by alias); 9 Dec 2015 18:48:49 -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 113944 invoked by uid 89); 9 Dec 2015 18:48:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.3 required=5.0 tests=AWL,BAYES_50 autolearn=ham version=3.3.2 X-HELO: mailrelay2.public.one.com Received: from mailrelay2.public.one.com (HELO mailrelay2.public.one.com) (91.198.169.125) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 09 Dec 2015 18:48:47 +0000 X-HalOne-Cookie: 5b7aec49ec989c85750ec12c2d0ee2bb240bffe6 X-HalOne-ID: 782692fc-9ea5-11e5-be90-b82a72d03b9b Received: from localhost.localdomain (unknown [91.135.11.213]) by smtpfilter2.public.one.com (Halon Mail Gateway) with ESMTPSA; Wed, 9 Dec 2015 18:48:41 +0000 (GMT) Subject: Re: [PATCH][ARC] Refurbish emitting DWARF2 for epilogue. To: Claudiu Zissulescu , "gcc-patches@gcc.gnu.org" References: <1448632380-7353-1-git-send-email-claziss@synopsys.com> <5660BB51.6000304@amylaar.uk> <098ECE41A0A6114BB2A07F1EC238DE896616B10C@de02wembxa.internal.synopsys.com> <5667B158.4020206@amylaar.uk> <098ECE41A0A6114BB2A07F1EC238DE896616B35C@de02wembxa.internal.synopsys.com> Cc: "Francois.Bedard@synopsys.com" , "jeremy.bennett@embecosm.com" From: Joern Wolfgang Rennecke Message-ID: <56687789.1040206@amylaar.uk> Date: Wed, 09 Dec 2015 18:48:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <098ECE41A0A6114BB2A07F1EC238DE896616B35C@de02wembxa.internal.synopsys.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2015-12/txt/msg01051.txt.bz2 On 09/12/15 15:34, Claudiu Zissulescu wrote: > Well, it seems to me that we prefer to disable optimizations when talking about debug related information (see PR target/60598 git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@208749 138bc75d-0d04-0410-961f-82ee72b054a4 commit). Actually, unwind information might also be needed for exception handling, depending on the target. (sjlj exception handling or dwarf2) In which case it becomes a matter of program correctness if any exception might be raised that could lead to incorrect unwinding due to incorrect/incomplete unwind info. So were both wrong: this is not merely about debugging. OTOH, the example you give also shows a much more nuanced approach to throttling optimization: the patch doesn't dead all epilogue scheduling, but specifically tests for the presence of a frame related insn at the point where it could cause trouble. The equivalent would be to reject a frame related insn in the delay slot of a conditional branch. For arc.md, that would likely involve splitting four of the define_delay statements into two each. If that seems a bit much, a compromize would be to patch in_delay_slot, thus affecting unconditional branches too. More ambitious approaches would be to move the note to a (zero-sized, pseudo-)placeholder insn, or finding a way to make the dwarf2cfi cope with speculated frame related insns. Eg.g even if the delay slot is not anulled, could we mark the note as anulled? Another approach would be to fix fill_eager_delay_slots not to stuff unconditional frame related insns into non-anulled delay slots of conditional branches. Or have some target hook to make it not even bother filling delay slots speculatively; for targets that can fully unexpose the delay slot, like SH and ARC >= ARC700, this aspect of fill_eager_delay_slots only mucks up schedules and increases code size. > Unfortunately, dwarf2cfi checks the paths for consistency (dwarf2cfi.c:2284), throwing an error if those paths are not ok. Also, with ARC gcc we focus on Linux type of application, hence, the unwinding info needs to be consistent. > As far as I can see, having a sort of mno-epilogue-cfi option will just inhibit or not the emitting of the blockage instruction, and the option will be valid only when compiling without emitting dwarf information (i.e., the mno-epilogue-cfi is incompatible with -g). > Personally, I do not see the benefit of having such an option, as one may lose like 1 cycle per function call (HS/EM cpus) in very particular cases. Running the dg.exp, compile.exp, execute.exp, and builing Linux with some default apps, we found only 4 cases in which the branch scheduler slot needs the blockage mechanism. The number of problems you found needs not bear any relation to the number of optimizations suppressed by the blockage instruction. Consider the case when there are high-latency unconditional instructions just before a lengthy epilogue. sched2 scheduling some epilogue instructions into the scheduling bubbles can hide the latencies. More relevant ways to get data would be comparing the object files (from a whole toolchain library set and/or one or more big application(s)) built with/without the blockage insn emitted, or to benchmark it. > Also, adding blockage before generating any prologue instruction seems to be a wide spread practice in gcc backends (see SH for example). It is a quick way to 'fix' (actually, hide) bugs. At the expense of optimization. It can be justified if the resources to keep a port in working order are limited, and so are the forgone optimization benefits. But at a minimum, you should add a comment to explain what problem you are papering over. That works best if you actually file a bug report in bugzilla first (about the interaction of fill_eager_delay_slots and dwarf2cfi) so that you can name the bug.