[Bug tree-optimization/90271] [missed-optimization] failure to keep variables in registers during "faux" memcpy

2019-05-10 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90271 --- Comment #12 from Jakub Jelinek --- Author: jakub Date: Fri May 10 07:53:23 2019 New Revision: 271056 URL: https://gcc.gnu.org/viewcvs?rev=271056&root=gcc&view=rev Log: PR tree-optimization/88709 PR tree-optimization/90271

[Bug tree-optimization/90271] [missed-optimization] failure to keep variables in registers during "faux" memcpy

2019-05-06 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90271 --- Comment #11 from Jakub Jelinek --- Author: jakub Date: Mon May 6 21:50:14 2019 New Revision: 270924 URL: https://gcc.gnu.org/viewcvs?rev=270924&root=gcc&view=rev Log: PR tree-optimization/88709 PR tree-optimization/90271

[Bug tree-optimization/90271] [missed-optimization] failure to keep variables in registers during "faux" memcpy

2019-04-30 Thread eyalroz at technion dot ac.il
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90271 --- Comment #10 from Eyal Rozenberg --- (In reply to rguent...@suse.de from comment #9) > You'd have to experiment with different GCC versions, but yes. I was hoping for a more concrete suggestion (which works with multiple GCC versions)...

[Bug tree-optimization/90271] [missed-optimization] failure to keep variables in registers during "faux" memcpy

2019-04-30 Thread rguenther at suse dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90271 --- Comment #9 from rguenther at suse dot de --- On April 29, 2019 9:23:21 PM GMT+02:00, "eyalroz at technion dot ac.il" wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90271 > >--- Comment #8 from Eyal Rozenberg --- >(In reply to rguent..

[Bug tree-optimization/90271] [missed-optimization] failure to keep variables in registers during "faux" memcpy

2019-04-29 Thread eyalroz at technion dot ac.il
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90271 --- Comment #8 from Eyal Rozenberg --- (In reply to rguent...@suse.de from comment #5) > int foo3() > { > struct { int x; int y; } s; > s.x = 3; > char c = 1; > return replace_bytes_3(&s.x,c); > } > > Coalescing successful! > Merged into

[Bug tree-optimization/90271] [missed-optimization] failure to keep variables in registers during "faux" memcpy

2019-04-29 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90271 --- Comment #7 from Jakub Jelinek --- On the store-merging side --- gimple-ssa-store-merging.c.jj 2019-01-01 12:37:19.063943678 +0100 +++ gimple-ssa-store-merging.c 2019-04-29 16:45:38.333266338 +0200 @@ -4164,7 +4164,8 @@ lhs_valid_for_st

[Bug tree-optimization/90271] [missed-optimization] failure to keep variables in registers during "faux" memcpy

2019-04-28 Thread eyalroz at technion dot ac.il
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90271 --- Comment #6 from Eyal Rozenberg --- > Is the example from real-world code? Yes. Example: Some machines support atomic instructions on aligned 32 bits or on 64 bits, but not directly on 1, 2, 3, 5, 6 or 7 bytes. So in order to atomically chang

[Bug tree-optimization/90271] [missed-optimization] failure to keep variables in registers during "faux" memcpy

2019-04-28 Thread rguenther at suse dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90271 --- Comment #5 from rguenther at suse dot de --- On Sun, 28 Apr 2019, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90271 > > --- Comment #4 from Jakub Jelinek --- > One thing is that store-merging doesn't opti

[Bug tree-optimization/90271] [missed-optimization] failure to keep variables in registers during "faux" memcpy

2019-04-28 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90271 Richard Biener changed: What|Removed |Added CC||jakub at gcc dot gnu.org,

[Bug tree-optimization/90271] [missed-optimization] failure to keep variables in registers during "faux" memcpy

2019-04-28 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90271 --- Comment #4 from Jakub Jelinek --- One thing is that store-merging doesn't optimize this, I think we have an open enhancement request for that that should be able to cure that case. Another one is that perhaps we should consider such MEM_REFs