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

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

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

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

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

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) >>>

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

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

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)) ==

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

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

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

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,

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

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'

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

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. > >

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

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

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

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.

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

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

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

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

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]

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

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 >

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

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

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. >

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

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

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. > >

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

[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