public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [PATCH] Use move-aware auto_vec in map
@ 2024-06-28  6:42 Jørgen Kvalsvik
  2024-06-28 11:55 ` Richard Biener
  0 siblings, 1 reply; 3+ messages in thread
From: Jørgen Kvalsvik @ 2024-06-28  6:42 UTC (permalink / raw)
  To: gcc-patches; +Cc: hubicka, Jørgen Kvalsvik

Using auto_vec rather than vec for means the vectors are release
automatically upon return, to stop the leak. The problem seems is that
auto_vec<T, N> is not really move-aware, only the <T, 0> specialization
is.

This is actually Jan's original suggestion
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655600.html which I
improvised on by also using embedded storage. I think it should fix this
regression:
https://gcc.gnu.org/pipermail/gcc-regression/2024-June/080152.html

I could not reproduce it on x86-64 linux, so if someone could help me
test it on aarch64 that would be much appreciated.

--

gcc/ChangeLog:

	* tree-profile.cc (find_conditions): Use auto_vec without
          embedded storage.
---
 gcc/tree-profile.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/tree-profile.cc b/gcc/tree-profile.cc
index 8c9945847ca..153c9323040 100644
--- a/gcc/tree-profile.cc
+++ b/gcc/tree-profile.cc
@@ -876,7 +876,7 @@ find_conditions (struct function *fn)
     make_top_index (fnblocks, ctx.B1, ctx.top_index);
 
     /* Bin the Boolean expressions so that exprs[id] -> [x1, x2, ...].  */
-    hash_map<int_hash<unsigned, 0>, auto_vec<basic_block, 8>> exprs;
+    hash_map<int_hash<unsigned, 0>, auto_vec<basic_block>> exprs;
     for (basic_block b : fnblocks)
     {
 	const unsigned uid = condition_uid (fn, b);
-- 
2.39.2


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] Use move-aware auto_vec in map
  2024-06-28  6:42 [PATCH] Use move-aware auto_vec in map Jørgen Kvalsvik
@ 2024-06-28 11:55 ` Richard Biener
  2024-06-28 13:37   ` Jørgen Kvalsvik
  0 siblings, 1 reply; 3+ messages in thread
From: Richard Biener @ 2024-06-28 11:55 UTC (permalink / raw)
  To: Jørgen Kvalsvik; +Cc: gcc-patches, hubicka

On Fri, Jun 28, 2024 at 8:43 AM Jørgen Kvalsvik <j@lambda.is> wrote:
>
> Using auto_vec rather than vec for means the vectors are release
> automatically upon return, to stop the leak. The problem seems is that
> auto_vec<T, N> is not really move-aware, only the <T, 0> specialization
> is.

Indeed.

> This is actually Jan's original suggestion
> https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655600.html which I
> improvised on by also using embedded storage. I think it should fix this
> regression:
> https://gcc.gnu.org/pipermail/gcc-regression/2024-June/080152.html
>
> I could not reproduce it on x86-64 linux, so if someone could help me
> test it on aarch64 that would be much appreciated.

OK.

> --
>
> gcc/ChangeLog:
>
>         * tree-profile.cc (find_conditions): Use auto_vec without
>           embedded storage.
> ---
>  gcc/tree-profile.cc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/tree-profile.cc b/gcc/tree-profile.cc
> index 8c9945847ca..153c9323040 100644
> --- a/gcc/tree-profile.cc
> +++ b/gcc/tree-profile.cc
> @@ -876,7 +876,7 @@ find_conditions (struct function *fn)
>      make_top_index (fnblocks, ctx.B1, ctx.top_index);
>
>      /* Bin the Boolean expressions so that exprs[id] -> [x1, x2, ...].  */
> -    hash_map<int_hash<unsigned, 0>, auto_vec<basic_block, 8>> exprs;
> +    hash_map<int_hash<unsigned, 0>, auto_vec<basic_block>> exprs;
>      for (basic_block b : fnblocks)
>      {
>         const unsigned uid = condition_uid (fn, b);
> --
> 2.39.2
>

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] Use move-aware auto_vec in map
  2024-06-28 11:55 ` Richard Biener
@ 2024-06-28 13:37   ` Jørgen Kvalsvik
  0 siblings, 0 replies; 3+ messages in thread
From: Jørgen Kvalsvik @ 2024-06-28 13:37 UTC (permalink / raw)
  To: Richard Biener; +Cc: gcc-patches, hubicka

On 6/28/24 13:55, Richard Biener wrote:
> On Fri, Jun 28, 2024 at 8:43 AM Jørgen Kvalsvik <j@lambda.is> wrote:
>>
>> Using auto_vec rather than vec for means the vectors are release
>> automatically upon return, to stop the leak. The problem seems is that
>> auto_vec<T, N> is not really move-aware, only the <T, 0> specialization
>> is.
> 
> Indeed.
> 
>> This is actually Jan's original suggestion
>> https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655600.html which I
>> improvised on by also using embedded storage. I think it should fix this
>> regression:
>> https://gcc.gnu.org/pipermail/gcc-regression/2024-June/080152.html
>>
>> I could not reproduce it on x86-64 linux, so if someone could help me
>> test it on aarch64 that would be much appreciated.
> 
> OK.

Pushed. Sorry for the noise.

Thanks,
Jørgen

> 
>> --
>>
>> gcc/ChangeLog:
>>
>>          * tree-profile.cc (find_conditions): Use auto_vec without
>>            embedded storage.
>> ---
>>   gcc/tree-profile.cc | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/gcc/tree-profile.cc b/gcc/tree-profile.cc
>> index 8c9945847ca..153c9323040 100644
>> --- a/gcc/tree-profile.cc
>> +++ b/gcc/tree-profile.cc
>> @@ -876,7 +876,7 @@ find_conditions (struct function *fn)
>>       make_top_index (fnblocks, ctx.B1, ctx.top_index);
>>
>>       /* Bin the Boolean expressions so that exprs[id] -> [x1, x2, ...].  */
>> -    hash_map<int_hash<unsigned, 0>, auto_vec<basic_block, 8>> exprs;
>> +    hash_map<int_hash<unsigned, 0>, auto_vec<basic_block>> exprs;
>>       for (basic_block b : fnblocks)
>>       {
>>          const unsigned uid = condition_uid (fn, b);
>> --
>> 2.39.2
>>


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2024-06-28 13:37 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-06-28  6:42 [PATCH] Use move-aware auto_vec in map Jørgen Kvalsvik
2024-06-28 11:55 ` Richard Biener
2024-06-28 13:37   ` Jørgen Kvalsvik

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).