Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

On Fri, Mar 09, 2018 at 09:48:45AM +, Bin.Cheng wrote: > On Wed, Feb 28, 2018 at 6:17 AM, Alexandre Oliva wrote: > > On Feb 21, 2018, Alexandre Oliva wrote: > > > >> On Feb 15, 2018, Szabolcs Nagy wrote: > >>> i see assembler slow downs with these location view patches > >>> i opened https:/

Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

On Fri, Mar 9, 2018 at 9:48 AM, Bin.Cheng wrote: > On Wed, Feb 28, 2018 at 6:17 AM, Alexandre Oliva wrote: >> On Feb 21, 2018, Alexandre Oliva wrote: >> >>> On Feb 15, 2018, Szabolcs Nagy wrote: i see assembler slow downs with these location view patches i opened https://gcc.gnu.org/b

Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

On Wed, Feb 28, 2018 at 6:17 AM, Alexandre Oliva wrote: > On Feb 21, 2018, Alexandre Oliva wrote: > >> On Feb 15, 2018, Szabolcs Nagy wrote: >>> i see assembler slow downs with these location view patches >>> i opened https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84408 > > >> [LVU] reset view at

Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

On 02/21/2018 03:11 AM, Alexandre Oliva wrote: > On Feb 15, 2018, Szabolcs Nagy wrote: > >> i see assembler slow downs with these location view patches >> i opened https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84408 > > > [LVU] reset view at function entry, omit views at line zero > > Location

Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

On Feb 21, 2018, Alexandre Oliva wrote: > On Feb 15, 2018, Szabolcs Nagy wrote: >> i see assembler slow downs with these location view patches >> i opened https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84408 > [LVU] reset view at function entry, omit views at line zero Ping? https://gcc.gnu.or

Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

On Wed, Feb 21, 2018 at 11:32 AM, Alexandre Oliva wrote: > On Jan 24, 2018, Jakub Jelinek wrote: > >>> --- a/gcc/tree-ssa-live.c >>> +++ b/gcc/tree-ssa-live.c >>> @@ -520,6 +520,11 @@ remove_unused_scope_block_p (tree scope, bool >>> in_ctor_dtor_block) >>> else if (!BLOCK_SUPERCONTEXT (scope) >

Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

On 21/02/18 10:11, Alexandre Oliva wrote: On Feb 15, 2018, Szabolcs Nagy wrote: i see assembler slow downs with these location view patches i opened https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84408 [LVU] reset view at function entry, omit views at line zero Location views might be associ

Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

On Wed, Feb 21, 2018 at 11:11 AM, Alexandre Oliva wrote: > On Feb 15, 2018, Szabolcs Nagy wrote: > >> i see assembler slow downs with these location view patches >> i opened https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84408 > > > [LVU] reset view at function entry, omit views at line zero > > Lo

Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

On Jan 24, 2018, Jakub Jelinek wrote: >> --- a/gcc/tree-ssa-live.c >> +++ b/gcc/tree-ssa-live.c >> @@ -520,6 +520,11 @@ remove_unused_scope_block_p (tree scope, bool >> in_ctor_dtor_block) >> else if (!BLOCK_SUPERCONTEXT (scope) >> || TREE_CODE (BLOCK_SUPERCONTEXT (scope)) == FUNCTION_DECL) >> u

Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

On Feb 15, 2018, Szabolcs Nagy wrote: > i see assembler slow downs with these location view patches > i opened https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84408 [LVU] reset view at function entry, omit views at line zero Location views might be associated with locations that lack line number

Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

On 13/02/18 13:43, Alexandre Oliva wrote: On Feb 12, 2018, Alexandre Oliva wrote: This patch supersedes the previous one. Testing underway... Ok if it succeeds? I failed to update the patch I posted after making a correct to symbol poisoning, that had caused builds to fail right away, sorr

Re: [SFN+LVU+IEPM v4 7/9] [LVU] Introduce location views

On Feb 13 2018, Alexandre Oliva wrote: > The patch I posted last night should work around this problem, in that > it will disable LVU by default if the assembler doesn't support .loc > views, and then you won't get this error any more, unless you explicitly > ask for location views. If you can g

Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

On 02/13/2018 06:43 AM, Alexandre Oliva wrote: > On Feb 12, 2018, Alexandre Oliva wrote: > >> This patch supersedes the previous one. Testing underway... Ok if it >> succeeds? > > I failed to update the patch I posted after making a correct to symbol > poisoning, that had caused builds to fail

Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

On Feb 12, 2018, Alexandre Oliva wrote: > This patch supersedes the previous one. Testing underway... Ok if it > succeeds? I failed to update the patch I posted after making a correct to symbol poisoning, that had caused builds to fail right away, sorry. Thanks, Rainer, for catching the error

Re: [SFN+LVU+IEPM v4 7/9] [LVU] Introduce location views

On Feb 12, 2018, Andreas Schwab wrote: > On Feb 12 2018, Alexandre Oliva wrote: >> On Feb 11, 2018, Andreas Schwab wrote: >> >>> On Feb 09 2018, Alexandre Oliva wrote: >> + if (list_head->vl_symbol && dwarf2out_locviews_in_attribute ()) +{ + ASM_OUTPUT_LABEL (asm_out

Re: [SFN+LVU+IEPM v4 7/9] [LVU] Introduce location views

On Feb 12 2018, Alexandre Oliva wrote: > On Feb 11, 2018, Andreas Schwab wrote: > >> On Feb 09 2018, Alexandre Oliva wrote: > >>> + if (list_head->vl_symbol && dwarf2out_locviews_in_attribute ()) >>> +{ >>> + ASM_OUTPUT_LABEL (asm_out_file, list_head->vl_symbol); > >> That needs to us

Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

On Feb 9, 2018, Alexandre Oliva wrote: > On Feb 9, 2018, Jakub Jelinek wrote: >> On Fri, Feb 09, 2018 at 07:01:25PM -0200, Alexandre Oliva wrote: >>> So, as discussed on IRC, I'm trying to use a target hook to allow >>> targets to indicate that their length attrs have been assessed for this >>

Re: [SFN+LVU+IEPM v4 7/9] [LVU] Introduce location views

On Feb 11, 2018, Andreas Schwab wrote: > On Feb 09 2018, Alexandre Oliva wrote: >> + if (list_head->vl_symbol && dwarf2out_locviews_in_attribute ()) >> +{ >> + ASM_OUTPUT_LABEL (asm_out_file, list_head->vl_symbol); > That needs to use ASM_OUTPUT_DEBUG_LABEL. Note this is always outp

Re: [SFN+LVU+IEPM v4 7/9] [LVU] Introduce location views

On Feb 11, 2018, Andreas Schwab wrote: >> + if (list_head->vl_symbol && dwarf2out_locviews_in_attribute ()) >> +{ >> + ASM_OUTPUT_LABEL (asm_out_file, list_head->vl_symbol); > That needs to use ASM_OUTPUT_DEBUG_LABEL. There's another use of the same macro that was already there, right

Re: [SFN+LVU+IEPM v4 7/9] [LVU] Introduce location views

On Feb 09 2018, Alexandre Oliva wrote: > @@ -9681,34 +9978,85 @@ gen_llsym (dw_loc_list_ref list) > static void > output_loc_list (dw_loc_list_ref list_head) > { > + int vcount = 0, lcount = 0; > + >if (list_head->emitted) > return; >list_head->emitted = true; > > + if (list_h

Re: [SFN+LVU+IEPM v4 7/9] [LVU] Introduce location views

On Feb 09 2018, Alexandre Oliva wrote: > [LVU] Introduce location views > > This patch introduces an option to enable the generation of location > views along with location lists. The exact format depends on the > DWARF version: it can be a separate attribute (DW_AT_GNU_locviews) or > (DW_LLE_vi

Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

On Feb 10, 2018, Jeff Law wrote: >> Ports call final_scan_insn with seen == NULL, and then >> maybe_output_next_view crashes because it assumes it's >> non-NULL. Oops. Fixed. > A bit icky. But OK. Thanks. Testing revealed some ports had already introduced their own 'seen' variables passed to

Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

On 02/10/2018 05:34 AM, Alexandre Oliva wrote: > Hi, Joseph, > > On Feb 9, 2018, Joseph Myers wrote: > >> sh4 is: >> during RTL pass: final >> In file included from strtof_l.c:45: >> strtod_l.c: In function 'strtof_l_internal': >> strtod_l.c:1769:1: internal compiler error: Segmentation fau

Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

On 02/10/2018 06:04 AM, Alexandre Oliva wrote: > On Feb 10, 2018, Jeff Law wrote: > >> So given what I've seen in the ARM port, I don't think we can generally >> assume any insn advances the PC. > > Ugh. Thanks, I'll adjust the patch to not count call insns, I guess. > > Maybe what we should h

Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

On Feb 10, 2018, Jeff Law wrote: > So given what I've seen in the ARM port, I don't think we can generally > assume any insn advances the PC. Ugh. Thanks, I'll adjust the patch to not count call insns, I guess. Maybe what we should have is some target hook that, instead of vowing for ATTR_leng

Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

Hi, Joseph, On Feb 9, 2018, Joseph Myers wrote: > sh4 is: > during RTL pass: final > In file included from strtof_l.c:45: > strtod_l.c: In function 'strtof_l_internal': > strtod_l.c:1769:1: internal compiler error: Segmentation fault > } > ^ > 0xb98e3f crash_signal > /scratch/jmy

Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

On 02/09/2018 09:39 PM, Alexandre Oliva wrote: > On Feb 9, 2018, Alexandre Oliva wrote: > >> On Feb 9, 2018, Jeff Law wrote: >>> On 02/08/2018 08:53 PM, Alan Modra wrote: On Fri, Feb 09, 2018 at 01:21:27AM -0200, Alexandre Oliva wrote: > Here's what I checked in, right after the LVU p

Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

On Feb 9, 2018, Alexandre Oliva wrote: > On Feb 9, 2018, Jeff Law wrote: >> On 02/08/2018 08:53 PM, Alan Modra wrote: >>> On Fri, Feb 09, 2018 at 01:21:27AM -0200, Alexandre Oliva wrote: Here's what I checked in, right after the LVU patch. [IEPM] Introduce inline entry point ma

Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

On Fri, 9 Feb 2018, Joseph Myers wrote: > I'm seeing regressions from my glibc bot for all of arm, mips, s390 and > sh. > > https://sourceware.org/ml/libc-testresults/2018-q1/msg00283.html > > arm and mips are "view number mismatch" building glibc and s390 is the > same error but building libg

Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

On Feb 9, 2018, Jakub Jelinek wrote: > On Fri, Feb 09, 2018 at 07:01:25PM -0200, Alexandre Oliva wrote: >> So, as discussed on IRC, I'm trying to use a target hook to allow >> targets to indicate that their length attrs have been assessed for this >> purpose, and a param to make that overridable

Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

On Fri, Feb 09, 2018 at 07:01:25PM -0200, Alexandre Oliva wrote: > So, as discussed on IRC, I'm trying to use a target hook to allow > targets to indicate that their length attrs have been assessed for this > purpose, and a param to make that overridable, but I'm having trouble > initializing the p

Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

I'm seeing regressions from my glibc bot for all of arm, mips, s390 and sh. https://sourceware.org/ml/libc-testresults/2018-q1/msg00283.html arm and mips are "view number mismatch" building glibc and s390 is the same error but building libgcc, so presumably those are the present issue. sh is

Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

On Feb 9, 2018, Jeff Law wrote: > On 02/08/2018 08:53 PM, Alan Modra wrote: >> On Fri, Feb 09, 2018 at 01:21:27AM -0200, Alexandre Oliva wrote: >>> Here's what I checked in, right after the LVU patch. >>> >>> [IEPM] Introduce inline entry point markers >> >> One of these two patches breaks ppc

Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

On 02/09/2018 03:34 AM, Alexandre Oliva wrote: > On Feb 9, 2018, Jeff Law wrote: > >> On 02/08/2018 08:53 PM, Alan Modra wrote: >>> On Fri, Feb 09, 2018 at 01:21:27AM -0200, Alexandre Oliva wrote: Here's what I checked in, right after the LVU patch. [IEPM] Introduce inline entry p

Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

On Fri, Feb 09, 2018 at 08:34:08AM -0200, Alexandre Oliva wrote: > * config/rs6000/rs6000.md (blockage): Set length to zero. Thanks! This fixed the ppc64le libdecnumber error for me. -- Alan Modra Australia Development Lab, IBM

Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

On Feb 9, 2018, Jeff Law wrote: > On 02/08/2018 08:53 PM, Alan Modra wrote: >> On Fri, Feb 09, 2018 at 01:21:27AM -0200, Alexandre Oliva wrote: >>> Here's what I checked in, right after the LVU patch. >>> >>> [IEPM] Introduce inline entry point markers >> >> One of these two patches breaks ppc

Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

On 02/08/2018 08:53 PM, Alan Modra wrote: > On Fri, Feb 09, 2018 at 01:21:27AM -0200, Alexandre Oliva wrote: >> Here's what I checked in, right after the LVU patch. >> >> [IEPM] Introduce inline entry point markers > > One of these two patches breaks ppc64le bootstrap with the assembler > complain

Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

On Fri, Feb 09, 2018 at 01:21:27AM -0200, Alexandre Oliva wrote: > Here's what I checked in, right after the LVU patch. > > [IEPM] Introduce inline entry point markers One of these two patches breaks ppc64le bootstrap with the assembler complaining "Error: view number mismatch" when compiling lib

Re: [SFN+LVU+IEPM v4 7/9] [LVU] Introduce location views

On Feb 8, 2018, Jason Merrill wrote: > On Thu, Feb 8, 2018 at 7:56 AM, Alexandre Oliva wrote: >> On Feb 7, 2018, Jason Merrill wrote: >> >>> OK, that makes sense. But I'm still uncomfortable with choosing an >>> existing opcode for that purpose, which previously would have been >>> chosen j

Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

On Jan 25, 2018, Alexandre Oliva wrote: > On Jan 24, 2018, Jakub Jelinek wrote: >> I think this asks for >> if (flag_checking) >> gcc_assert (block_within_block_p (block, >> DECL_INITIAL (current_function_decl), >> true)); > 'k, changed. >> Otherwise the patch looks reasonable to me, but I thi

Re: [SFN+LVU+IEPM v4 7/9] [LVU] Introduce location views

On Feb 8, 2018, Jason Merrill wrote: > On 02/07/2018 02:36 AM, Alexandre Oliva wrote: >> +/* Output symbol LAB1 as an unsigned LEB128 quantity. */ > Let's mention here that the value of LAB1 must be an assemble-time > constant (such as a view counter), since we can't have LEB128 > relocations.

Re: [SFN+LVU+IEPM v4 7/9] [LVU] Introduce location views

On 02/07/2018 02:36 AM, Alexandre Oliva wrote: +/* Output symbol LAB1 as an unsigned LEB128 quantity. */ Let's mention here that the value of LAB1 must be an assemble-time constant (such as a view counter), since we can't have LEB128 relocations. With that, the patch looks OK. Jason

Re: [SFN+LVU+IEPM v4 7/9] [LVU] Introduce location views

On Thu, Feb 8, 2018 at 7:56 AM, Alexandre Oliva wrote: > On Feb 7, 2018, Jason Merrill wrote: > >> OK, that makes sense. But I'm still uncomfortable with choosing an >> existing opcode for that purpose, which previously would have been >> chosen just for reasons of encoding complexity and size.

Re: [SFN+LVU+IEPM v4 7/9] [LVU] Introduce location views

On Feb 7, 2018, Jason Merrill wrote: > OK, that makes sense. But I'm still uncomfortable with choosing an > existing opcode for that purpose, which previously would have been > chosen just for reasons of encoding complexity and size. Well, there's a good reason we didn't used to output this op

Re: [SFN+LVU+IEPM v4 7/9] [LVU] Introduce location views

On 02/06/2018 11:02 PM, Alexandre Oliva wrote: On Feb 6, 2018, Jason Merrill wrote: On 12/11/2017 09:52 PM, Alexandre Oliva wrote: Why do we need to use a non-zero view identifier for a zero view? Why can't we always use 0 instead of the bitmap? We assign view ids before we can determine

Re: [SFN+LVU+IEPM v4 7/9] [LVU] Introduce location views

On Jan 25, 2018, Alexandre Oliva wrote: > On Jan 24, 2018, Jakub Jelinek wrote: >> On Tue, Dec 12, 2017 at 12:52:18AM -0200, Alexandre Oliva wrote: >>> +DW_LLE_GNU_view_pair = 0x09, >>> +#define DW_LLE_view_pair DW_LLE_GNU_view_pair >> This looks wrong. The proposal has not been accepted y

Re: [SFN+LVU+IEPM v4 7/9] [LVU] Introduce location views

Here's the updated version of the LVU patch, integrating changes requested or proposed by yourself and by Jakub. for include/ChangeLog * dwarf2.def (DW_AT_GNU_locviews): New. * dwarf2.h (enum dwarf_location_list_entry_type): Add DW_LLE_GNU_view_pair. (DW_LLE_view

Re: [SFN+LVU+IEPM v4 7/9] [LVU] Introduce location views

Here's an incremental patch with the changes I made in response to your requests. I'll post the complete updated patch momentarily. diff --git a/gcc/common.opt b/gcc/common.opt index 55d9cdd714ff..7e024fdab124 100644 --- a/gcc/common.opt +++ b/gcc/common.opt @@ -2957,9 +2957,12 @@ Common Driver R

Re: [SFN+LVU+IEPM v4 7/9] [LVU] Introduce location views

On Jan 30, 2018, Richard Sandiford wrote: >> But it is my understanding that both of the following are correct: >> >> return (verylongcondition >> && otherlongcondition__); >> >> return verylongcondition

Re: [SFN+LVU+IEPM v4 7/9] [LVU] Introduce location views

On Feb 6, 2018, Jason Merrill wrote: > On 12/11/2017 09:52 PM, Alexandre Oliva wrote: >> +/* output symbol LAB1 as an unsigned LEB128 quantity. */ >> + >> +void >> +dw2_asm_output_symname_uleb128 (const char *lab1 ATTRIBUTE_UNUSED, >> +const char *comment, ...) > I'

Re: [SFN+LVU+IEPM v4 7/9] [LVU] Introduce location views

On 12/11/2017 09:52 PM, Alexandre Oliva wrote: +/* output symbol LAB1 as an unsigned LEB128 quantity. */ + +void +dw2_asm_output_symname_uleb128 (const char *lab1 ATTRIBUTE_UNUSED, + const char *comment, ...) I'm having trouble understanding the use of symbols for

Re: [SFN+LVU+IEPM v4 7/9] [LVU] Introduce location views

Alexandre Oliva writes: > On Jan 26, 2018, Jakub Jelinek wrote: > >> Having to tweak debug info consumers so that they treat DW_LLE_* of 9 >> one way for .debug_loclist of version 5 and another way for .debug_loclist >> of version 6 isn't a good idea. > > Maybe we don't have to do that. The reas

Re: [SFN+LVU+IEPM v4 7/9] [LVU] Introduce location views

On Jan 26, 2018, Jakub Jelinek wrote: > Having to tweak debug info consumers so that they treat DW_LLE_* of 9 > one way for .debug_loclist of version 5 and another way for .debug_loclist > of version 6 isn't a good idea. Maybe we don't have to do that. The reason I implemented the proposed form

Re: [SFN+LVU+IEPM v4 7/9] [LVU] Introduce location views

On Thu, Jan 25, 2018 at 05:58:37PM -0200, Alexandre Oliva wrote: > > This looks wrong. The proposal has not been accepted yet, so you > > really can't know if DW_LLE_view_pair will be like that or whether it > > will have value of 9. Unfortunately, the DWARF standard doesn't specify a > > vendor

Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

On Jan 24, 2018, Jakub Jelinek wrote: > I think this asks for > if (flag_checking) > gcc_assert (block_within_block_p (block, > DECL_INITIAL (current_function_decl), > true)); 'k, changed. > Otherwise the patch looks

Re: [SFN+LVU+IEPM v4 7/9] [LVU] Introduce location views

On Jan 24, 2018, Jakub Jelinek wrote: > On Tue, Dec 12, 2017 at 12:52:18AM -0200, Alexandre Oliva wrote: >> --- a/include/dwarf2.h >> +++ b/include/dwarf2.h >> @@ -298,6 +298,14 @@ enum dwarf_location_list_entry_type >> DW_LLE_start_end = 0x07, >> DW_LLE_start_length = 0x08, >> >> + /* >>

Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

On Tue, Dec 12, 2017 at 12:54:13AM -0200, Alexandre Oliva wrote: > +/* Check whether BLOCK, a lexical block, is nested within OUTER, or is > + OUTER itself. If BOTHWAYS, check not only that BLOCK can reach > + OUTER through BLOCK_SUPERCONTEXT links, but also that there is a > + path from OUT

Re: [SFN+LVU+IEPM v4 7/9] [LVU] Introduce location views

On Tue, Dec 12, 2017 at 12:52:18AM -0200, Alexandre Oliva wrote: > --- a/include/dwarf2.h > +++ b/include/dwarf2.h > @@ -298,6 +298,14 @@ enum dwarf_location_list_entry_type > DW_LLE_start_end = 0x07, > DW_LLE_start_length = 0x08, > > +/* >

Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

On Dec 21, 2017, Jeff Law wrote: > On 12/11/2017 07:54 PM, Alexandre Oliva wrote: >> + ASM_GENERATE_INTERNAL_LABEL (label, "LVU", ied->view); >> + /* FIXME: this will resolve to a small number. Could we >> + possibly emit smaller data? Ideally we'd emit a >> +

Re: [SFN+LVU+IEPM v4 6/9] [SFN] Introduce -gstatement-frontiers option, enable debug markers

On Mon, Dec 11, 2017 at 6:42 PM, Alexandre Oliva wrote: > On Dec 7, 2017, Jeff Law wrote: > >> On 11/09/2017 07:34 PM, Alexandre Oliva wrote: >>> Introduce a command line option to enable statement frontiers, enabled >>> by default in optimized builds with DWARF2+ debug information. >> OK once a

Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

On 12/11/2017 07:54 PM, Alexandre Oliva wrote: > On Nov 10, 2017, Alexandre Oliva wrote: > >> Output DW_AT_entry_pc based on markers. > > Here's an updated version of the patch. > > [IEPM] Introduce inline entry point markers > > Output DW_AT_entry_pc based on markers. > > Introduce DW_AT_GNU

Re: [SFN+LVU+IEPM v4 1/9] [SFN] adjust RTL insn-walking API

On Dec 14, 2017, Jakub Jelinek wrote: > On Thu, Dec 14, 2017 at 09:55:30AM -0200, Alexandre Oliva wrote: >> for gcc/ChangeLog > Please fix up formatting. Otherwise LGTM. Thanks, here's what I ended up installing (formatting fixes were slightly different from what you suggested, but to the sam

Re: [SFN+LVU+IEPM v4 1/9] [SFN] adjust RTL insn-walking API

On Thu, Dec 14, 2017 at 09:55:30AM -0200, Alexandre Oliva wrote: > for gcc/ChangeLog > > PR bootstrap/83396 > * config/arc/arc.c (hwloop_optimize): Skip debug insns. > * config/sh/sh-protos.h (sh_find_set_of_reg): Adjust. > * config/sh/sh.c: Skip debug insns besides notes.

Re: [SFN+LVU+IEPM v4 1/9] [SFN] adjust RTL insn-walking API

On Dec 12, 2017, Alexandre Oliva wrote: > On Dec 7, 2017, Jeff Law wrote: >> On 11/09/2017 07:34 PM, Alexandre Oliva wrote: >>> (prev_nonnote_insn_bb, next_nonnote_insn_bb): Remove. > Thanks, FTR, here it is, as installed: On Aug 31, 2017, Alexandre Oliva wrote: > (prev_nonnote_insn_bb

Re: [SFN+LVU+IEPM v4 6/9] [SFN] Introduce -gstatement-frontiers option, enable debug markers

On Dec 12, 2017, Christophe Lyon wrote: > Since this was checked in, I've noticed GCC/libatomic build failures > on ARM targets when configuring > --with-mode thumb (--with-mode arm is OK). Could you possibly provide me with preprocessed source that exercises the error, so that I could duplicate

Re: [SFN+LVU+IEPM v4 6/9] [SFN] Introduce -gstatement-frontiers option, enable debug markers

Hi, On 12 December 2017 at 03:42, Alexandre Oliva wrote: > On Dec 7, 2017, Jeff Law wrote: > >> On 11/09/2017 07:34 PM, Alexandre Oliva wrote: >>> Introduce a command line option to enable statement frontiers, enabled >>> by default in optimized builds with DWARF2+ debug information. >> OK onc

Re: [SFN+LVU+IEPM v4 1/9] [SFN] adjust RTL insn-walking API

On Dec 7, 2017, Jeff Law wrote: > On 11/09/2017 07:34 PM, Alexandre Oliva wrote: >> This patch removes unused RTL functions, introduces alternate ones for >> use in a later SFN patch, and regroups other related functions so that >> they appear in a more consistent order. >> >> for gcc/ChangeLo

Re: [SFN+LVU+IEPM v4 2/9] [SFN] boilerplate changes in preparation to introduce nonbind markers

On Dec 7, 2017, Jeff Law wrote: > On 11/09/2017 07:34 PM, Alexandre Oliva wrote: >> This patch introduces a number of new macros and functions that will > OK. Again, I think this can probably go in as-is. Thanks, FTR here's the installed patch: >From c64f38bf4d2f6c50fdc5122d129d2ad34088d19c M

Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

On Nov 10, 2017, Alexandre Oliva wrote: > Output DW_AT_entry_pc based on markers. Here's an updated version of the patch. [IEPM] Introduce inline entry point markers Output DW_AT_entry_pc based on markers. Introduce DW_AT_GNU_entry_view as a DWARF extension. If views are enabled are we're no

Re: [SFN+LVU+IEPM v4 7/9] [LVU] Introduce location views

On Dec 11, 2017, Jeff Law wrote: > On 11/09/2017 07:34 PM, Alexandre Oliva wrote: >> This patch introduces an option to enable the generation of location >> views along with location lists. The exact format depends on the >> void >> +dw2_asm_output_symname_uleb128 (const char *lab1 ATTRIBUTE_UNU

Re: [SFN+LVU+IEPM v4 8/9] [IEPM] Introduce debug hook for inline entry point markers

On Dec 7, 2017, Jeff Law wrote: > On 11/09/2017 07:34 PM, Alexandre Oliva wrote: >> The inline_entry hook will be given a definition in a later patch. >> >> for gcc/ChangeLog >> >> * debug.h (gcc_debug_hooks): Add inline_entry. >> * dbxout.c (dbx_debug_hooks, xcoff_debug_hooks): Likewise. >>

Re: [SFN+LVU+IEPM v4 6/9] [SFN] Introduce -gstatement-frontiers option, enable debug markers

On Dec 7, 2017, Jeff Law wrote: > On 11/09/2017 07:34 PM, Alexandre Oliva wrote: >> Introduce a command line option to enable statement frontiers, enabled >> by default in optimized builds with DWARF2+ debug information. > OK once all prereqs are ack'd. Thanks, here's what's installed, FTR: >F

Re: [SFN+LVU+IEPM v4 5/9] [SFN] introduce statement frontier notes, still disabled

On Dec 7, 2017, Jeff Law wrote: > On 11/09/2017 07:34 PM, Alexandre Oliva wrote: >> This patch completes the infrastructure for the introduction of >> statement frontiers in C-family languages. > Note I expect minor updates will be necessary due to the Cilk+ removal. > Such changes are pre-appro

Re: [SFN+LVU+IEPM v4 4/9] [SFN] stabilize find_bb_boundaries

On Dec 7, 2017, Jeff Law wrote: > On 11/09/2017 07:34 PM, Alexandre Oliva wrote: >> * cfgbuild.c (find_bb_boundaries): Don't purge dead edges if, >> without debug insns, we wouldn't, but clean up debug insns >> after a control flow insn nevertheless. > OK. Seems to me like it's independent of t

Re: [SFN+LVU+IEPM v4 3/9] [SFN] not-quite-boilerplate changes in preparation to introduce nonbind markers

On Dec 7, 2017, Jeff Law wrote: > On 11/09/2017 07:34 PM, Alexandre Oliva wrote: >> This patch adjusts numerous parts of the compiler that would > OK. > I'll note you may need minor tweaks due to the Cilk+ removal. THose > changes are pre-approved. Thanks, here's what I've just installed: >

Re: [SFN+LVU+IEPM v4 7/9] [LVU] Introduce location views

On 11/09/2017 07:34 PM, Alexandre Oliva wrote: > This patch introduces an option to enable the generation of location > views along with location lists. The exact format depends on the > DWARF version: it can be a separate attribute (DW_AT_GNU_locviews) or > (DW_LLE_view_pair) entries in DWARF5+ l

Re: [SFN+LVU+IEPM v4 5/9] [SFN] introduce statement frontier notes, still disabled

On 11/09/2017 07:34 PM, Alexandre Oliva wrote: > This patch completes the infrastructure for the introduction of > statement frontiers in C-family languages. > > It brings in all the code remaining code needed to introduce and > transform begin stmt trees, gimple stmts, insns and notes, and > ulti

Re: [SFN+LVU+IEPM v4 8/9] [IEPM] Introduce debug hook for inline entry point markers

On 11/09/2017 07:34 PM, Alexandre Oliva wrote: > The inline_entry hook will be given a definition in a later patch. > > for gcc/ChangeLog > > * debug.h (gcc_debug_hooks): Add inline_entry. > * dbxout.c (dbx_debug_hooks, xcoff_debug_hooks): Likewise. > * debug.c (do_nothing_debu

Re: [SFN+LVU+IEPM v4 6/9] [SFN] Introduce -gstatement-frontiers option, enable debug markers

On 11/09/2017 07:34 PM, Alexandre Oliva wrote: > Introduce a command line option to enable statement frontiers, enabled > by default in optimized builds with DWARF2+ debug information. > > This patch depends on an earlier patch that completed the > infrastructure for debug markers, and on another

Re: [SFN+LVU+IEPM v4 4/9] [SFN] stabilize find_bb_boundaries

On 11/09/2017 07:34 PM, Alexandre Oliva wrote: > If find_bb_boundaries is given a block with zero or one nondebug insn > beside debug insns, it shouldn't purge dead edges, because without > debug insns we wouldn't purge them at that point. Doing so may change > the order in which edges are process

Re: [SFN+LVU+IEPM v4 3/9] [SFN] not-quite-boilerplate changes in preparation to introduce nonbind markers

On 11/09/2017 07:34 PM, Alexandre Oliva wrote: > This patch adjusts numerous parts of the compiler that would > malfunction should they find debug markers at points where they may be > introduced. The changes purport to allow the compiler to pass > bootstrap-debug-lean (-fcompare-debug in stage3)

Re: [SFN+LVU+IEPM v4 2/9] [SFN] boilerplate changes in preparation to introduce nonbind markers

On 11/09/2017 07:34 PM, Alexandre Oliva wrote: > This patch introduces a number of new macros and functions that will > be used to distinguish between different kinds of debug stmts, insns > and notes, namely, preexisting debug bind ones and to-be-introduced > nonbind markers. > > In a seemingly m

Re: [SFN+LVU+IEPM v4 1/9] [SFN] adjust RTL insn-walking API

On 11/09/2017 07:34 PM, Alexandre Oliva wrote: > This patch removes unused RTL functions, introduces alternate ones for > use in a later SFN patch, and regroups other related functions so that > they appear in a more consistent order. > > for gcc/ChangeLog > > * emit-rtl.c (next_nondebug_i

Re: [SFN+LVU+IEPM v4 7/9] [LVU] Introduce location views

On Nov 13, 2017, Richard Biener wrote: > What does final.c need langhooks for? Thanks for catching this. At some point I had a check on whether there could be being stmt markers emitted by the language, but that's long gone, in part because of LTO; that's now computed dynamically, on a per-func

Re: [SFN+LVU+IEPM v4 7/9] [LVU] Introduce location views

On Fri, Nov 10, 2017 at 3:34 AM, Alexandre Oliva wrote: > This patch introduces an option to enable the generation of location > views along with location lists. The exact format depends on the > DWARF version: it can be a separate attribute (DW_AT_GNU_locviews) or > (DW_LLE_view_pair) entries in

Re: SFN+LVU+IEPM v4

On Nov 10, 2017, Alexandre Oliva wrote: > Most of the patchset is already approved, part by richi, part by jeff. > The only points still requiring changes, AFAIK, are the ones mentioned > above. Actually, I've just noticed that there's one big patch in the set that's still missing review and app

[SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

Output DW_AT_entry_pc based on markers. Introduce DW_AT_GNU_entry_view as a DWARF extension. If views are enabled are we're not in strict compliance mode, output DW_AT_GNU_entry_view if it might be nonzero. This patch depends on SFN and LVU patchsets, and on the IEPM patch that introduces the in

[SFN+LVU+IEPM v4 7/9] [LVU] Introduce location views

This patch introduces an option to enable the generation of location views along with location lists. The exact format depends on the DWARF version: it can be a separate attribute (DW_AT_GNU_locviews) or (DW_LLE_view_pair) entries in DWARF5+ loclists. Line number tables are also affected. If the

[SFN+LVU+IEPM v4 8/9] [IEPM] Introduce debug hook for inline entry point markers

The inline_entry hook will be given a definition in a later patch. for gcc/ChangeLog * debug.h (gcc_debug_hooks): Add inline_entry. * dbxout.c (dbx_debug_hooks, xcoff_debug_hooks): Likewise. * debug.c (do_nothing_debug_hooks): Likewise. * vmsdbgout.c (vmsdbg_debug

[SFN+LVU+IEPM v4 6/9] [SFN] Introduce -gstatement-frontiers option, enable debug markers

Introduce a command line option to enable statement frontiers, enabled by default in optimized builds with DWARF2+ debug information. This patch depends on an earlier patch that completed the infrastructure for debug markers, and on another patch that turns -g into a negatable option prefix. gcc/

[SFN+LVU+IEPM v4 5/9] [SFN] introduce statement frontier notes, still disabled

This patch completes the infrastructure for the introduction of statement frontiers in C-family languages. It brings in all the code remaining code needed to introduce and transform begin stmt trees, gimple stmts, insns and notes, and ultimately use them to generate the is_stmt column in DWARF2+ l

[SFN+LVU+IEPM v4 3/9] [SFN] not-quite-boilerplate changes in preparation to introduce nonbind markers

This patch adjusts numerous parts of the compiler that would malfunction should they find debug markers at points where they may be introduced. The changes purport to allow the compiler to pass bootstrap-debug-lean (-fcompare-debug in stage3) at various optimization levels, as well as bootstrap-de

[SFN+LVU+IEPM v4 4/9] [SFN] stabilize find_bb_boundaries

If find_bb_boundaries is given a block with zero or one nondebug insn beside debug insns, it shouldn't purge dead edges, because without debug insns we wouldn't purge them at that point. Doing so may change the order in which edges are processed, and ultimately lead to different transformations to

[SFN+LVU+IEPM v4 2/9] [SFN] boilerplate changes in preparation to introduce nonbind markers

This patch introduces a number of new macros and functions that will be used to distinguish between different kinds of debug stmts, insns and notes, namely, preexisting debug bind ones and to-be-introduced nonbind markers. In a seemingly mechanical way, it adjusts several uses of the macros and fu

[SFN+LVU+IEPM v4 1/9] [SFN] adjust RTL insn-walking API

This patch removes unused RTL functions, introduces alternate ones for use in a later SFN patch, and regroups other related functions so that they appear in a more consistent order. for gcc/ChangeLog * emit-rtl.c (next_nondebug_insn, prev_nondebug_insn): Reorder. (next_nonnote_no

SFN+LVU+IEPM v4 (was: Re: Statement Frontier Notes, Location Views, and Inlined Entry Point Markers)

On Sep 30, 2017, Alexandre Oliva wrote: > On Aug 31, 2017, Alexandre Oliva wrote: >> On Aug 23, 2017, Richard Biener wrote: >>> Just separating the boilerplate changes out from the "meat" of the change >>> into a separate patch for easier reviewing would be nice. >> I've broken up the patch in