[Bug middle-end/90216] Stack Pointer decrementing even when not loading extra data to stack.

2019-04-27 Thread stevexiong98 at hotmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90216

--- Comment #2 from stevexiong98 at hotmail dot com ---
(In reply to Andrew Pinski from comment #1)
> Confirmed, part of the problem is union is forced to memory early on but
> then optimized out but the object still exist in memory even though it is
> dead.
> I am working on an optimization which improves this by the lowering of
> bit-fields.  But it won't go in until post GCC 9 (released next year).

Thanks so much for the update. I am looking forward to the next compiler
release!

[Bug c++/90217] New: Greater optimization of C++ Code

2019-04-23 Thread stevexiong98 at hotmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90217

Bug ID: 90217
   Summary: Greater optimization of C++ Code
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stevexiong98 at hotmail dot com
  Target Milestone: ---

Hi,

This is not so much a bug, but more of an enhancement. There are 2 pieces of
code I have listed below which should translate to identical assembly
instructions at high levels of compiler optimization (level 3) but currently do
not.

https://godbolt.org/z/Zn7FMK
https://godbolt.org/z/wB8eZd


Using ARM GCC 8.2, the code in the second link involves the stack pointer and
extra load/store operations to the newly-created stack space. There are more
assembly instructions in link 2's code than in link 1's code. 

However, in Godbolt if you switch the compiler to Clang, at optimization 3 both
pieces of code manage to compile down to the same minimal Assembly
instructions.

Switching the compiler to x86-64 GCC (trunk), the code in the second link also
has a few extra operations compared the first link's code. 

Is it possible to set ARM GCC and x86-64 GCC to a particular optimization
setting that allows both links' code to have matching assembly instructions? If
not, is it possible that in a future release, both compilers could apply enough
optimizations so that the assembly in link 1 matches link 2?

Thanks

[Bug c++/90216] New: Stack Pointer decrementing even when not loading extra data to stack.

2019-04-23 Thread stevexiong98 at hotmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90216

Bug ID: 90216
   Summary: Stack Pointer decrementing even when not loading extra
data to stack.
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stevexiong98 at hotmail dot com
  Target Milestone: ---

Hi,

Using ARM GCC 8.2, when I instantiate an object the corresponding Assembly
instructions involve a decrementing, then incrementing of the stack pointer.
However, no values are being transferred between the registers and the empty
stack space. 

Please check out this link for details, lines 5 and 7 in the Assembly panel
show how the stack pointer is decremented/incremented unnecessarily.

https://godbolt.org/z/h-H7Ox

In the C++ panel when you comment out line 53 and uncomment the line below, the
Assembly instructions involving the stack pointer disappear. The same is true
if you uncomment just line 55.

Can you please explain why the stack pointer inc/dec operations are not
optimized out in the first line of code (line 53)? Can you please try to
release a patch where this unnecessary stack pointer inc/dec is no longer an
issue?

Thanks