On Thu, 29 Oct 2020, Jan Hubicka wrote:
> Hi,
> this patch removes second char array from tree_def union and makes it
> !TYPELESS_STORAGE. Now all accesses to anything in tree no longer have alias
> set 0, but they all have alias set 1 :)
> This is because the way we handle unions. However it still increases TBAA
> effectivity by about 12%. From:
>
> Alias oracle query stats:
> refs_may_alias_p: 65066258 disambiguations, 74846942 queries
> ref_maybe_used_by_call_p: 152444 disambiguations, 65966862 queries
> call_may_clobber_ref_p: 22546 disambiguations, 28559 queries
> nonoverlapping_component_refs_p: 0 disambiguations, 36816 queries
> nonoverlapping_refs_since_match_p: 27230 disambiguations, 58300 must
> overlaps, 86300 queries
> aliasing_component_refs_p: 66090 disambiguations, 2048800 queries
> TBAA oracle: 25578632 disambiguations 59483650 queries
> 12219919 are in alias set 0
> 10534575 queries asked about the same object
> 125 queries asked about the same alias set
> 0 access volatile
> 9491563 are dependent in the DAG
> 1658836 are aritificially in conflict with void *
>
> Modref stats:
> modref use: 14421 disambiguations, 48129 queries
> modref clobber: 1528229 disambiguations, 1926907 queries
> 3881547 tbaa queries (2.014392 per modref query)
> 565057 base compares (0.293246 per modref query)
>
> PTA query stats:
> pt_solution_includes: 947491 disambiguations, 13119151 queries
> pt_solutions_intersect: 1043695 disambiguations, 13221495 queries
>
> To:
>
> Alias oracle query stats:
> refs_may_alias_p: 66455561 disambiguations, 75202803 queries
> ref_maybe_used_by_call_p: 155301 disambiguations, 67370278 queries
> call_may_clobber_ref_p: 22550 disambiguations, 28587 queries
> nonoverlapping_component_refs_p: 0 disambiguations, 37058 queries
> nonoverlapping_refs_since_match_p: 28126 disambiguations, 59906 must
> overlaps, 88990 queries
> aliasing_component_refs_p: 66375 disambiguations, 2440039 queries
> TBAA oracle: 28800751 disambiguations 64328055 queries
> 8053661 are in alias set 0
> 11181983 queries asked about the same object
> 125 queries asked about the same alias set
> 0 access volatile
> 13905691 are dependent in the DAG
> 2385844 are aritificially in conflict with void *
>
> Modref stats:
> modref use: 16781 disambiguations, 52031 queries
> modref clobber: 1745589 disambiguations, 2149518 queries
> 4192266 tbaa queries (1.950328 per modref query)
> 559148 base compares (0.260127 per modref query)
>
> PTA query stats:
> pt_solution_includes: 906487 disambiguations, 13105994 queries
> pt_solutions_intersect: 1041144 disambiguations, 13659726 queries
>
> Bootstrapped/regtested x86_64-linux, OK?
>
> * tree.c (build_string): Update.
> * tree-core.h (tree_fixed_cst): Avoid typeless storage.
>
> diff --git a/gcc/tree-core.h b/gcc/tree-core.h
> index c9280a8d3b1..63dbb5b8eab 100644
> --- a/gcc/tree-core.h
> +++ b/gcc/tree-core.h
> @@ -1401,7 +1401,8 @@ struct GTY(()) tree_fixed_cst {
> struct GTY(()) tree_string {
> struct tree_typed typed;
> int length;
> - char str[1];
> + /* Avoid char array that would make whole type to be typeless storage. */
> + struct {char c;} str[1];
That's ugly and will for sure defeat warning / access code
when we access this as char[], no? I mean, we could
as well use 'int str[1];' here?
Maybe we can invent some C++ attribute for this?
[[gnu::string]]
or so that marks it as actual char and not typeless storage?
Richard.
> };
>
> struct GTY(()) tree_complex {
> diff --git a/gcc/tree.c b/gcc/tree.c
> index 81f867ddded..84115630184 100644
> --- a/gcc/tree.c
> +++ b/gcc/tree.c
> @@ -2273,7 +2273,7 @@ build_string (unsigned len, const char *str /*= NULL */)
> memcpy (s->string.str, str, len);
> else
> memset (s->string.str, 0, len);
> - s->string.str[len] = '\0';
> + s->string.str[len].c = '\0';
>
> return s;
> }
>
--
Richard Biener <rguent...@suse.de>
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imend
