Avoid char[] array in tree_def

[Richard Biener]

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 <rguenther@suse.de>
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imend