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

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

On Thu, 6 Feb 2020, Moritz Strübe wrote: > Why is this so hard optimize? As it's quite a common pattern I'd expect that > there would be at least some hand-coded special case optimizer. (This isn't > criticism - I'm honestly curious.) Or is there a reason gcc shouldn't optimize > this / Why it does

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

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

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

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?

On Mon, Apr 9, 2012 at 8:00 AM, Bin.Cheng wrote: > On Fri, Mar 30, 2012 at 5:43 PM, Bin.Cheng wrote: >> On Fri, Mar 30, 2012 at 4:15 PM, Richard Guenther >> wrote: >>> On Thu, Mar 29, 2012 at 5:25 PM, Bin.Cheng wrote: On Thu, Mar 29, 2012 at 6:14 PM, Richard Guenther wrote: > On

Re: Missed optimization in PRE?

On Fri, Mar 30, 2012 at 5:43 PM, Bin.Cheng wrote: > On Fri, Mar 30, 2012 at 4:15 PM, Richard Guenther > wrote: >> On Thu, Mar 29, 2012 at 5:25 PM, Bin.Cheng wrote: >>> On Thu, Mar 29, 2012 at 6:14 PM, Richard Guenther >>> wrote: On Thu, Mar 29, 2012 at 12:10 PM, Bin.Cheng wrote: > On

Re: Missed optimization in PRE?

On Fri, Mar 30, 2012 at 4:15 PM, Richard Guenther wrote: > On Thu, Mar 29, 2012 at 5:25 PM, Bin.Cheng wrote: >> On Thu, Mar 29, 2012 at 6:14 PM, Richard Guenther >> wrote: >>> On Thu, Mar 29, 2012 at 12:10 PM, Bin.Cheng wrote: On Thu, Mar 29, 2012 at 6:07 PM, Richard Guenther wrote:

Re: Missed optimization in PRE?

On Thu, Mar 29, 2012 at 5:25 PM, Bin.Cheng wrote: > On Thu, Mar 29, 2012 at 6:14 PM, Richard Guenther > wrote: >> On Thu, Mar 29, 2012 at 12:10 PM, Bin.Cheng wrote: >>> 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

Re: Missed optimization in PRE?

On Thu, Mar 29, 2012 at 6:14 PM, Richard Guenther wrote: > On Thu, Mar 29, 2012 at 12:10 PM, Bin.Cheng wrote: >> 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 pro

Re: Missed optimization in PRE?

On Thu, Mar 29, 2012 at 6:14 PM, Richard Guenther wrote: > On Thu, Mar 29, 2012 at 12:10 PM, Bin.Cheng wrote: >> 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 pro

Re: Missed optimization in PRE?

On Thu, Mar 29, 2012 at 12:10 PM, Bin.Cheng wrote: > 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

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

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 symbolic range

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

On Sat, May 21, 2011 at 9:07 AM, Matt Turner wrote: > Hi, > > While trying to optimize pixman, I noticed that gcc is unable to > recognize that 'while (n >= 1)' can often be simplified to 'if (n >= > 1)'. Consider the following example, where there are loops that > operate on larger amounts of dat