Re: Please review writeup for fixing PR 78809 (inline strcmp for small constant strings)

On November 17, 2017 11:20:45 PM GMT+01:00, Qing Zhao wrote: > >> On Nov 16, 2017, at 6:24 PM, Martin Sebor wrote: >>> >>> In my current local implementation, I used the following routine to >get the range info: (and use the MINMAXLEN[1]+1 for the length of the >non-constant string) >>> >>> /

Re: Please review writeup for fixing PR 78809 (inline strcmp for small constant strings)

On 11/17/2017 03:20 PM, Qing Zhao wrote: > >> On Nov 16, 2017, at 6:24 PM, Martin Sebor > > wrote: >>> >>> In my current local implementation, I used the following routine to >>> get the range info:  (and use the MINMAXLEN[1]+1 for the length of >>> the non-constant string

Re: Please review writeup for fixing PR 78809 (inline strcmp for small constant strings)

On 11/17/2017 03:50 PM, Qing Zhao wrote: >> >> The difficulty is tracking when exposure leads to these secondary >> opportunities. I often end up looking for this kind of stuff by first >> identifying many source files where the transformation applies. Then I >> generate dumps & assembly code fo

Re: Please review writeup for fixing PR 78809 (inline strcmp for small constant strings)

On 11/17/2017 03:45 PM, Qing Zhao wrote: >>> do you think using this routine is good? or do you have other >>> suggestions (since I am still not very familiar with the internals of >>> GCC, might not find the best available one now…) >> The range information attached to an SSA_NAME is global data.

Re: Please review writeup for fixing PR 78809 (inline strcmp for small constant strings)

On 11/17/2017 04:08 PM, Qing Zhao wrote: On Nov 17, 2017, at 1:50 AM, Jakub Jelinek wrote: On Thu, Nov 16, 2017 at 06:14:35PM -0700, Jeff Law wrote: However, this routine currently miss a very obvious case as the following: char s[100] = {'a','b','c','d’}; __builtin_strcmp(s, "abc") != 0

Re: Please review writeup for fixing PR 78809 (inline strcmp for small constant strings)

> On Nov 17, 2017, at 1:50 AM, Jakub Jelinek wrote: > > On Thu, Nov 16, 2017 at 06:14:35PM -0700, Jeff Law wrote: >>> However, this routine currently miss a very obvious case as the following: >>> >>> char s[100] = {'a','b','c','d’}; >>> >>> __builtin_strcmp(s, "abc") != 0 >>> >>> So, I have

Re: Please review writeup for fixing PR 78809 (inline strcmp for small constant strings)

A would like to be put in gimple fold phase (in routine "gimple_fold_builtin_string_compare" of gimple-fold.c >> OK. Note that various optimizations can expose N or one of the strings >>> to be a constant. So having it as part of the folders makes a lot of >>> sense . >>

Re: Please review writeup for fixing PR 78809 (inline strcmp for small constant strings)

Hi, Jeff, > On Nov 16, 2017, at 7:14 PM, Jeff Law wrote: >> >> In my current local implementation, I used the following routine to get >> the range info: (and use the MINMAXLEN[1]+1 for the length of the >> non-constant string) >> >> /* Determine the minimum and maximum value or string length

Re: Please review writeup for fixing PR 78809 (inline strcmp for small constant strings)

> On Nov 16, 2017, at 6:24 PM, Martin Sebor wrote: >> >> In my current local implementation, I used the following routine to get the >> range info: (and use the MINMAXLEN[1]+1 for the length of the non-constant >> string) >> >> /* Determine the minimum and maximum value or string length that

Re: Please review writeup for fixing PR 78809 (inline strcmp for small constant strings)

> On Nov 16, 2017, at 5:55 PM, Martin Sebor wrote: >> >> A. for strncmp (s1, s2, n) >> if one of "s1" or "s2" is a constant string, "n" is a constant, and >> larger than the length of the constant string: >> change strncmp (s1, s2, n) to strcmp (s1, s2); > > Here and I think in som

superior language dwarf records

Hello, We want to add source-level debugging to GNU Cobol. The Cobol compiler generates C, and then invokes gcc to produce ELF object code, of course. We are entertaining approaches to replace/amplify the DWARF records produced by gcc with new ones referencing the Cobol source. Before diving

Re: Missed possible branch elimination

On Thu, Oct 26, 2017 at 8:23 PM, Stefan Ring wrote: > While poring over the Transport Tycoon Deluxe disassembly, commonly > known to have been hand-written in assembler, I stumbled across this > tidbit, which I think is kinda neat: > > 004057F7 83 7D B8 01 cmp dword ptr [ebp-48h],

Re: Potential bug on Cortex-M due to used registers/interrupts.

Hi, > These other registers - r4 to r12 - are "callee saved". To be precise, R4-R11 are callee-saved, R0-R3, R12, LR are caller-saves and LR and PSR are clobbered by calls. LR is slightly odd in that it is a callee-save in the prolog, but not in the epilog (since LR is assumed clobbered after a c

Re: Potential bug on Cortex-M due to used registers/interrupts.

On 16/11/17 17:54, Vitalijus Jefišovas wrote: > On Cortex-M mcu’s, when interrupt happens, NVIC copies r0-r3 and couple > other registers onto the psp stack, and then jumps to interrupt routine, > when it finishes, NVIC restores these registers, and jumps back to user’s > function. > What is happen

CFG operation leading to errors

Hi, I've found a potential issue when performing CFG operations for hardware loops. When a port is using hardware loops (like ARC) makes use of reorg_loops to find and analyze loops that end in loop_end instructions. The very same function can be set to reorder the cfg such that the loop end oc

RE: Backporting ARC patch to gcc7.x

> We've generally considered those clauses under the umbrella of the port > maintainers. Thank you for your guidance. I've backported the patch using the gcc guideline: >svn commit Sending. Sendinggcc/ChangeLog Sendinggcc/config.gcc Sendinglibgcc/ChangeLog Sending