[Bug tree-optimization/92038] Extremely inefficient x86_64 code for trivally copyable types passed in registers.

[Bug tree-optimization/92038] Extremely inefficient x86_64 code for trivally copyable types passed in registers.

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92038

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|target                      |tree-optimization
           Severity|normal                      |enhancement

--- Comment #10 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Just summary now, reduced testcase in comment #6 is fixed but the original
testcase still does not get optimized to 0.

[Bug tree-optimization/92038] Extremely inefficient x86_64 code for trivally copyable types passed in registers.

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92038

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
Store-merging says

Starting active chain number 1 with statement:
MEM[(struct __as_base  &)&D.14275] ={v} {CLOBBER};
The base object is:
&D.14275
Recording immediate store from stmt:
MEM[(struct _Uninitialized *)&D.14275] ={v} {CLOBBER};
Recording immediate store from stmt:
MEM[(struct _Uninitialized *)&D.14275]._M_storage = 0;
Recording immediate store from stmt:
MEM[(struct _Variant_storage *)&D.14275]._M_index = 0;
stmt causes chain termination:
f (D.14275);
Terminating chain with 4 stores
Attempting to coalesce 4 stores in chain
...
After writing 0 of size 8 at position 32
  the merged value contains 00 00 00 00 00 00 00 00
  the merged mask contains  00 00 00 00 00 ff ff ff
Coalescing successful!
Merged into 1 stores
Exceeded original number of stmts (2).  Not profitable to emit new sequence.

(the non-details dump only says "Merged into 1 stores" which is confusing)

So it seems the trick fails to consider that we can enlarge the store
to cover tail-padding when we didn't see any earlier stores into it?

So the "C++ issue" is that we do

  MEM[(struct __as_base  &)&D.14275] ={v} {CLOBBER};

and thus only clobber the part w/o the tail padding (and std::variant isn't
'final').  Of course since this is an automatic object we do know it isn't
derived so we could have clobbered the whole object.

Not sure if that's visible at the point the C++ FE calls the CTOR.  I think
it is.  We generate:

;; Function void g() (null)
;; enabled by -tree-original


<<cleanup_point <<< Unknown tree: expr_stmt
  f (TARGET_EXPR <D.14275, <<< Unknown tree: aggr_init_expr
  4
  __ct_comp
  D.14275
  (struct variant *) <<< Unknown tree: void_cst >>> >>>>) >>>>>;

so why do we call the as-base CTOR?  Hmm, it seems this ends up as

  struct variant D.14275;

D.14275.D.14084.D.13569.D.13400.D.13268.D.13154.D.13046._M_u._M_first._M_storage
= 0;
  D.14275.D.14084.D.13569.D.13400.D.13268.D.13154.D.13046._M_index = 0;
  std::variant<int, int>::variant (&D.14275);

where the "self-CTOR" is the guilty one.  So maybe it's also a library
problem.