Re: Nested restrict pointers: missed optimization & client with UB?

> Am 13.02.2024 um 16:27 schrieb Ties Klappe via Gcc : > > Thank you both for your quick replies. > > @Joseph, thank you for linking me to the other issue. If I understand > correctly what the point is, would you then agree that the program main > when calling foo2 has *defined* behavior? > W

Re: Nested restrict pointers: missed optimization & client with UB?

On Tue, 13 Feb 2024, Ties Klappe via Gcc wrote: > Thank you both for your quick replies. > > @Joseph, thank you for linking me to the other issue. If I understand > correctly what the point is, would you then agree that the program main > when calling foo2 has *defined* behavior? I think that's

Re: Nested restrict pointers: missed optimization & client with UB?

Thank you both for your quick replies. @Joseph, thank you for linking me to the other issue. If I understand correctly what the point is, would you then agree that the program main when calling foo2 has *defined* behavior? What surprises me is that *p and *q might be the same restricted pointer: t

Re: Nested restrict pointers: missed optimization & client with UB?

On Tue, 13 Feb 2024, Ties Klappe via Gcc wrote: > int foo2(int *restrict *p, int *restrict *q) > { > **p = 10; > **q = 11; > return **p; > } In this case, *p and *q might be the same restricted pointer object. See the more detailed explanation at

Re: Nested restrict pointers: missed optimization & client with UB?

&xp); > > return 0; > } > > So to wrap up, I have two questions: > > 1. Should *foo2* be optimized in the same way as *foo1* and is it simply a > missed optimization candidate, or is there another reason GCC does not > optimize it? > 2. Does the client *main*

Nested restrict pointers: missed optimization & client with UB?

the same way as *foo1* and is it simply a missed optimization candidate, or is there another reason GCC does not optimize it? 2. Does the client *main* contain undefined behavior according to GCC, and if so, why? Thank you in advance. Kind regards, Ties

Re: Missed optimization of strcpy(3) (or stpcpy(3))

Hi Richard, On Mon, Nov 13, 2023 at 07:56:00AM +0100, Richard Biener wrote: > Can you file a bugreport please? It looks like a transform for the > strlen pass. Done; thanks. -- signature.asc Description

Re: Missed optimization of strcpy(3) (or stpcpy(3))

On Sun, Nov 12, 2023 at 10:10 PM Alejandro Colomar via Gcc wrote: > > Hi, > > The following code can be optimized to use memcpy(3), since the length > of the copy is known (we've just called strnlen(3), and discarded the > possibility of truncated lengths). > > $ cat strxcpy.c > #include > #inclu

Missed optimization of strcpy(3) (or stpcpy(3))

Hi, The following code can be optimized to use memcpy(3), since the length of the copy is known (we've just called strnlen(3), and discarded the possibility of truncated lengths). $ cat strxcpy.c #include #include #include ssize_t strxcpy(char *restrict dst, const char *restrict src, size_t d

Re: Missed optimization with endian and alignment independent memory access on x64

INT_MIN): int f(unsigned char *ptr, int i) { return ptr[i] | ptr[i+1] << 8; } With 64-bit address space this might access two bytes 4GB apart. But you're right that it's a missed optimization in GCC, so you can file it to the GCC Bugzilla. > Is there a way to write such code that gcc

Missed optimization with endian and alignment independent memory access on x64

Hey, a pattern I see quite often in embedded libraries is to access an array byte wise and shift the bits as needed (as this fixes endianness and alignment issues). If I read two consecutive bytes and left-shift the second by 8, I'd expect the compiler to optimize this to a word read on a x64

Re: Missed optimization with const member

On 07/07/2017 06:26 AM, Ion Gaztañaga wrote: On 05/07/2017 17:24, Martin Sebor wrote: [*] While the example (copied below) is valid, accessing the object after someFunction() has returned via a reference or pointer to it is not. void somefunction(const Object& object); { void* p = &

Re: Missed optimization with const member

On 05/07/2017 17:24, Martin Sebor wrote: [*] While the example (copied below) is valid, accessing the object after someFunction() has returned via a reference or pointer to it is not. void somefunction(const Object& object); { void* p = &object; object.~Object(); new(p) Obj

Re: Missed optimization with const member

On Wed, Jul 5, 2017 at 12:14 PM, Jonathan Wakely wrote: > On 5 July 2017 at 10:13, Oleg Endo wrote: >> Hi, >> >> On Wed, 2017-07-05 at 02:02 +0200, Geza Herman wrote: >>> >>> Here's what happens: in callInitA(), an Object put onto the stack (which >>> has a const member variable, initialized to 0)

Re: Missed optimization with const member

On 07/05/2017 01:26 PM, Geza Herman wrote: On 07/05/2017 01:14 PM, Jonathan Wakely wrote: I think the reason it's not optimized away is for this case: void somefunction(const Object& object); { void* p = &object; object.~Object(); new(p) Object(); } This means that after calling someF

Re: Missed optimization with const member

On 07/04/2017 06:02 PM, Geza Herman wrote: Hi, I've included a small program at the end of my email. Here's what happens: in callInitA(), an Object put onto the stack (which has a const member variable, initialized to 0). Then somefunction called (which is intentionally not defined). Then ~Obje

Re: Missed optimization with const member

On Wed, 2017-07-05 at 12:14 +0100, Jonathan Wakely wrote: >  > No, that would be undefined behaviour. The data member is defined as > const, so it's not possible to write to that member without undefined > behaviour. A variable defined with a const type is not the same as a > variable accessed thro

Re: Missed optimization with const member

On 07/05/2017 01:14 PM, Jonathan Wakely wrote: I think the reason it's not optimized away is for this case: void somefunction(const Object& object); { void* p = &object; object.~Object(); new(p) Object(); } This means that after calling someFunction there could be a different object at

Re: Missed optimization with const member

On 5 July 2017 at 10:13, Oleg Endo wrote: > Hi, > > On Wed, 2017-07-05 at 02:02 +0200, Geza Herman wrote: >> >> Here's what happens: in callInitA(), an Object put onto the stack (which >> has a const member variable, initialized to 0). Then somefunction called >> (which is intentionally not defined

Re: Missed optimization with const member

Hi, On Wed, 2017-07-05 at 02:02 +0200, Geza Herman wrote: >  > Here's what happens: in callInitA(), an Object put onto the stack (which  > has a const member variable, initialized to 0). Then somefunction called  > (which is intentionally not defined). Then ~Object() is called, which  > has an "if

Missed optimization with const member

Hi, I've included a small program at the end of my email. Here's what happens: in callInitA(), an Object put onto the stack (which has a const member variable, initialized to 0). Then somefunction called (which is intentionally not defined). Then ~Object() is called, which has an "if", which

Re: Possible missed optimization opportunity with const?

On 18/08/16 00:44, Toshi Morita wrote: > David Brown wrote: > >> No, it would not be valid. Declaring pfoo as a "const int*" tells the >> compiler "I will not change anything via this pointer - and you can >> optimise based on that promise". It does /not/ tell the compiler "the >> thing that th

Re: Possible missed optimization opportunity with const?

use 2016-08-17 - 发件人：Toshi Morita 发送日期：2016-08-17 08:21 收件人：gcc@gcc.gnu.org 抄送： 主题：Possible missed optimization opportunity with const? I was involved in a discussion over the semantics of "const" in C, and the following code was posted: #include int foo = 0; const in

Re: Possible missed optimization opportunity with const?

for the code to print a:0, b: 0? If so, is this a missed optimization opportunity? No, it would not be valid. Declaring pfoo as a "const int*" tells the compiler "I will not change anything via this pointer - and you can optimise based on that promise". It does /not/ tell

Re: missed optimization

On Tue, Sep 29, 2015 at 11:20 PM, Richard Biener wrote: > On September 29, 2015 9:27:13 PM GMT+02:00, fxcoud...@gmail.com wrote: >>It cannot be done in the front-end, but has to happen during value >>propagation in the middle-end. But the middle-end only handles known >>*_EXPR and built-ins. So th

Re: missed optimization

On September 29, 2015 9:27:13 PM GMT+02:00, fxcoud...@gmail.com wrote: >It cannot be done in the front-end, but has to happen during value >propagation in the middle-end. But the middle-end only handles known >*_EXPR and built-ins. So this would require adding either a POWINT_EXPR >or a type-generi

Re: missed optimization

It cannot be done in the front-end, but has to happen during value propagation in the middle-end. But the middle-end only handles known *_EXPR and built-ins. So this would require adding either a POWINT_EXPR or a type-generic __builtin_powint. No small task. I think there is already a PR for th

Re: missed optimization

Hi Steve, subroutine foo(n) integer n integer i, j i = 2 j = 4 n = i**j ! <-- This should evaluate to 16 without a function call. end subroutine foo To do this in the Fortran front end would require constant propagation, which we currently do not do. We do not

missed optimization

There appears to be a missed opportunity to optimize away exponential operators. I suspect that this falls under gfortrani's frontend-optimize option, but it may also be a middle-end issue. Consider, subroutine foo(n) integer n integer i, j i = 2 j = 4 n = i**j ! <-- Th

Re: Missed optimization case

On Tue, Dec 23, 2014 at 2:25 PM, Andi Kleen wrote: > > Please file a bug with a test case. No need to worry about the phase > too much initially, just fill in a reasonable component. > Thanks - filed as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64396 -matt

Re: Missed optimization case

Matt Godbolt writes: > > I'll happily file a bug if necessary but I'm not clear in what phase > the optimization opportunity has been missed. Please file a bug with a test case. No need to worry about the phase too much initially, just fill in a reasonable component. -Andi

Missed optimization case

Hi all, While digging into some GCC-generated code, I noticed a missed opportunity in GCC that Clang and ICC seem to take advantage of. All versions of GCC (up to 4.9.0) seem to have the same trouble. The following source (for x86_64) shows up the problem: - #include #define add_carry32(sum

Re: Missed optimization in PRE?

On Wed, Apr 11, 2012 at 11:25 AM, Bin.Cheng wrote: > On Wed, Apr 11, 2012 at 5:09 PM, Richard Guenther > wrote: >> On Wed, Apr 11, 2012 at 10:05 AM, Bin.Cheng wrote: >>> On Wed, Apr 11, 2012 at 11:28 AM, Bin.Cheng wrote: > >>> >>> Turns out if-conversion checks whether gimple statement traps or

Re: Missed optimization in PRE?

On Wed, Apr 11, 2012 at 5:09 PM, Richard Guenther wrote: > On Wed, Apr 11, 2012 at 10:05 AM, Bin.Cheng wrote: >> On Wed, Apr 11, 2012 at 11:28 AM, Bin.Cheng wrote: >> >> Turns out if-conversion checks whether gimple statement traps or not. >> For the statement "d0_6 = d[D.5150_5];", it assumes

Re: Missed optimization in PRE?

On Wed, Apr 11, 2012 at 10:05 AM, Bin.Cheng wrote: > On Wed, Apr 11, 2012 at 11:28 AM, Bin.Cheng wrote: >> On Mon, Apr 9, 2012 at 7:02 PM, Richard Guenther >> wrote: >>> On Mon, Apr 9, 2012 at 8:00 AM, Bin.Cheng wrote: On Fri, Mar 30, 2012 at 5:43 PM, Bin.Cheng wrote: >> Hi Rich

Re: Missed optimization in PRE?

On Wed, Apr 11, 2012 at 11:28 AM, Bin.Cheng wrote: > On Mon, Apr 9, 2012 at 7:02 PM, Richard Guenther > wrote: >> On Mon, Apr 9, 2012 at 8:00 AM, Bin.Cheng wrote: >>> On Fri, Mar 30, 2012 at 5:43 PM, Bin.Cheng wrote: > >>> >>> Hi Richard, >>> I am testing a patch to sink load of memory to prope

Re: Missed optimization in PRE?

On Mon, Apr 9, 2012 at 7:02 PM, Richard Guenther wrote: > On Mon, Apr 9, 2012 at 8:00 AM, Bin.Cheng wrote: >> On Fri, Mar 30, 2012 at 5:43 PM, Bin.Cheng wrote: >> >> Hi Richard, >> I am testing a patch to sink load of memory to proper basic block. >> Everything goes fine except auto-vectorizati

Re: Missed optimization in PRE?

gt;, >>>>>>>> but why not lowered into basic block 3, where it is used. >>>>>>>> >>>>>>>> BTW, seems no tree pass handles this case currently. >>>>>>> >>>>>>> tree-ssa-sink.c should

Re: Missed optimization in PRE?

gt;>> >>>>>>> BTW, seems no tree pass handles this case currently. >>>>>> >>>>>> tree-ssa-sink.c should do this. >>>>>> >>>>> It does not work for me, I will double check and update soon. >>

Re: Missed optimization in PRE?

a-sink.c should do this. >>>>> >>>> It does not work for me, I will double check and update soon. >>> >>> Well, "should" as in, it's the place to do it.  And certainly the pass can >>> sink >>> loads, so this must be a mi

Re: Missed optimization in PRE?

why not lowered into basic block 3, where it is used. >>>>> >>>>> BTW, seems no tree pass handles this case currently. >>>> >>>> tree-ssa-sink.c should do this. >>>> >>> It does not work for me, I will double check and update soon. >>

Re: Missed optimization in PRE?

handles this case currently. >>> >>> tree-ssa-sink.c should do this. >>> >> It does not work for me, I will double check and update soon. > > Well, "should" as in, it's the place to do it.  And certainly the pass can > sink > loads, so th

Re: Missed optimization in PRE?

handles this case currently. >>> >>> tree-ssa-sink.c should do this. >>> >> It does not work for me, I will double check and update soon. > > Well, "should" as in, it's the place to do it.  And certainly the pass can > sink > loads, so this must be a missed optimization. > ok, I will investigate it. -- Best Regards.

Re: Missed optimization in PRE?

ot work for me, I will double check and update soon. Well, "should" as in, it's the place to do it. And certainly the pass can sink loads, so this must be a missed optimization. Richard. > -- > Best Regards.

Re: Missed optimization in PRE?

On Thu, Mar 29, 2012 at 6:07 PM, Richard Guenther wrote: > On Thu, Mar 29, 2012 at 12:02 PM, Bin.Cheng wrote: >> Hi, >> Following is the tree dump of 094t.pre for a test program. >> Question is loads of D.5375_12/D.5375_14 are redundant on path > bb7, bb5, bb6>, >> but why not lowered into basic

Re: Missed optimization in PRE?

On Thu, Mar 29, 2012 at 12:02 PM, Bin.Cheng wrote: > Hi, > Following is the tree dump of 094t.pre for a test program. > Question is loads of D.5375_12/D.5375_14 are redundant on path bb7, bb5, bb6>, > but why not lowered into basic block 3, where it is used. > > BTW, seems no tree pass handles th

Missed optimization in PRE?

Hi, Following is the tree dump of 094t.pre for a test program. Question is loads of D.5375_12/D.5375_14 are redundant on path , but why not lowered into basic block 3, where it is used. BTW, seems no tree pass handles this case currently. Any idea? Thanks int z$imag; int z$real; int D.5378

Re: [WIP PATCH] Re: Inefficient end-of-loop value computation - missed optimization somewhere?

On Tue, Feb 28, 2012 at 4:10 PM, Ulrich Weigand wrote: > Richard Guenther wrote: >> On Mon, Feb 20, 2012 at 11:19 PM, Ulrich Weigand wrote: >> > we've noticed that the loop optimizer sometimes inserts weirdly >> > inefficient code to compute the value of an induction variable >> > at the end of t

[WIP PATCH] Re: Inefficient end-of-loop value computation - missed optimization somewhere?

Richard Guenther wrote: > On Mon, Feb 20, 2012 at 11:19 PM, Ulrich Weigand wrote: > > we've noticed that the loop optimizer sometimes inserts weirdly > > inefficient code to compute the value of an induction variable > > at the end of the loop. [snip] > The issue is that (start + 1) + 1 * (int) .

Re: Inefficient end-of-loop value computation - missed optimization somewhere?

On Tue, Feb 21, 2012 at 1:27 AM, Richard Guenther wrote: > On Mon, Feb 20, 2012 at 11:19 PM, Ulrich Weigand wrote: >> Hello, >> >> we've noticed that the loop optimizer sometimes inserts weirdly >> inefficient code to compute the value of an induction variable >> at the end of the loop. >> >> As

Re: Inefficient end-of-loop value computation - missed optimization somewhere?

On Mon, Feb 20, 2012 at 11:19 PM, Ulrich Weigand wrote: > Hello, > > we've noticed that the loop optimizer sometimes inserts weirdly > inefficient code to compute the value of an induction variable > at the end of the loop. > > As a test case stripped down to the core of the problem, consider: > >

Inefficient end-of-loop value computation - missed optimization somewhere?

Hello, we've noticed that the loop optimizer sometimes inserts weirdly inefficient code to compute the value of an induction variable at the end of the loop. As a test case stripped down to the core of the problem, consider: int test (int start, int end) { int i; for (i = start; i < end; i+

Missed optimization opportunity

Hello, I've come across an issue when working on a smart pointer implementation. Gcc does not seem to propagate constants enough, missing some optimization opportunities. I don't think that this issue is specific to smart pointers, so there might be other cases when gcc generates suboptimal c

Re: missed optimization: transforming while(n>=1) into if(n>=1)

On 05/21/2011 08:07 AM, Matt Turner wrote: I suppose this is a missed optimization. Is this known, or should I make a new bug report? It's always better to do that. In this case, the bug is that when we compute a range from an ASSERT_EXPR, and the base variable has a known but sym

Re: missed optimization: transforming while(n>=1) into if(n>=1)

resulting machine code includes the backward branch to the top of > the while (n >= 1) loop, which can never be taken. > > I suppose this is a missed optimization. Is this known, or should I > make a new bug report? I have an old bugreport for a somewhat related problem: http

missed optimization: transforming while(n>=1) into if(n>=1)

never execute more than once, as n must be < 2, and in the body of the loop, n is decremented. The resulting machine code includes the backward branch to the top of the while (n >= 1) loop, which can never be taken. I suppose this is a missed optimization. Is this known, or should I make a new bug report? Thanks, Matt Turner

Re: [4.2] MIPS: missed optimization

Manuel Lauss <[EMAIL PROTECTED]> writes: > On Sun, Nov 23, 2008 at 05:14:27PM +, Richard Sandiford wrote: >> Richard Sandiford <[EMAIL PROTECTED]> writes: >> > Manuel Lauss <[EMAIL PROTECTED]> writes: >> >> Admittedly my understanding of mips assembly is not yet very advanced, am >> >> I >> >>

Re: [4.2] MIPS: missed optimization

Hello Richard, On Sun, Nov 23, 2008 at 05:14:27PM +, Richard Sandiford wrote: > Richard Sandiford <[EMAIL PROTECTED]> writes: > > Manuel Lauss <[EMAIL PROTECTED]> writes: > >> Admittedly my understanding of mips assembly is not yet very advanced, am I > >> missing something or is this a bug? >

Re: [4.2] MIPS: missed optimization

Richard Sandiford <[EMAIL PROTECTED]> writes: > Manuel Lauss <[EMAIL PROTECTED]> writes: >> Admittedly my understanding of mips assembly is not yet very advanced, am I >> missing something or is this a bug? > > Well, it's a missed optimisation, certainly. Fortunately, > it's conceptually fairly ea

Re: [4.2] MIPS: missed optimization

Manuel Lauss <[EMAIL PROTECTED]> writes: > Admittedly my understanding of mips assembly is not yet very advanced, am I > missing something or is this a bug? Well, it's a missed optimisation, certainly. Fortunately, it's conceptually fairly easy to fix. I'll have a go. Richard

[4.2] MIPS: missed optimization

Hello, Please consider this little snippett of code: - 8< -- 8< -- #define AU1000_INTC0_INT_BASE 8 #define IC0_FALLINGCLR 0xb0400078 #define IC0_RISINGCLR 0xb040007c static inline void au_writel(unsigned long d, unsigned long a) { *(unsigned long *)(a) =

Re: PR 33089: Canonicalizing a + b != 0 as a != -b causes missed optimization

On Fri, 17 Aug 2007, Rask Ingemann Lambertsen wrote: >We start out with (eq (plus X A) 0): >I want to hear some opinions on which form we should choose as the > canonical one. I'm proposing two forms: > > 1) (eq (neg X) Y) because the change to simplify_comparison will be simpler. > 2) (e

PR 33089: Canonicalizing a + b != 0 as a != -b causes missed optimization

We start out with (eq (plus X A) 0): simplify_comparison (code=EQ, pop0=0xbfd722b4, pop1=0xbfd722b0) at /home/rask/cvssrc/ia16-gcc/gcc/combine.c:9915 (gdb) call debug_rtx (*pop0) (plus:SI (reg/v:SI 59 [ b ]) (mem/c/i:SI (reg/f:SI 16 argp) [2 a+0 S4 A32])) (gdb) call debug_rtx (*pop1) (co

Re: GCC missed optimization?

On 7/31/06, Devang Patel <[EMAIL PROTECTED]> wrote: >>I think this patch by Zdenek - vectorizing function calls - is related: >> http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01655.html >> (would need to be extended to cover this case). Yes, extending Zdenek's patch to recognize built-in is a

Re: GCC missed optimization?

>>I think this patch by Zdenek - vectorizing function calls - is related: >> http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01655.html >> (would need to be extended to cover this case). Yes, extending Zdenek's patch to recognize built-in is a good idea. However, in case of compiler inserted built-

Re: GCC missed optimization?

some benchmarking of gfortran, and reducing the > > testcase leads to what seems a missed optimization in the following > > code: > > > > $ cat a.c > > void foo (float * restrict x, float * restrict y) > > { > > int i; > > > > for (i = 0; i < 1000

Re: GCC missed optimization?

On Jul 28, 2006, at 3:04 AM, Richard Guenther wrote: A bugreport is useful so we don't forget. There is already a bug report. PR 21465. -- Pinski

Re: GCC missed optimization?

On 7/28/06, François-Xavier Coudert <[EMAIL PROTECTED]> wrote: I've been doing some benchmarking of gfortran, and reducing the testcase leads to what seems a missed optimization in the following code: $ cat a.c void foo (float * restrict x, float * restrict y) { int i; fo

GCC missed optimization?

I've been doing some benchmarking of gfortran, and reducing the testcase leads to what seems a missed optimization in the following code: $ cat a.c void foo (float * restrict x, float * restrict y) { int i; for (i = 0; i < 1; i++) x[i] = y[i] * y[i]; } $ gcc a.c -O1 -ffast-ma

missed-optimization issue count

For fun, I counted the number of open missed-optimization issues: all versions: 423 gcc-3.4.x: 55 gcc-4.0.x: 170 gcc-4.1-x: 93 It looks like many of them, even those filed four years ago, are getting some recent attention, which is encouraging. Thanks to everyone pushing these along. - Dan