public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Siddhesh Poyarekar <siddhesh@gotplt.org>
To: Jakub Jelinek <jakub@redhat.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH 04/10] tree-object-size: Single pass dependency loop resolution
Date: Tue, 23 Nov 2021 19:14:04 +0530	[thread overview]
Message-ID: <d4327a82-c175-bbe2-2353-bc49189d301d@gotplt.org> (raw)
In-Reply-To: <20211123120742.GV2646553@tucnak>

On 11/23/21 17:37, Jakub Jelinek wrote:
> On Wed, Nov 10, 2021 at 12:31:30AM +0530, Siddhesh Poyarekar wrote:
>> Use SSA names as placeholders self-referencing variables to generate
>> expressions for object sizes and then reduce those size expressions
>> to constants instead of repeatedly walking through statements.
>>
>> This change also makes sure that object sizes for an SSA name are
>> updated at most twice, once if there is a dependency loop and then the
>> final time upon computation of object size.  Iteration to deduce the
>> final size is now done on the size expressions instead of walking
>> through the object references.
>>
>> Added test to include a case where __builtin_object_size incorrectly
>> returned the minimum object size as zero.
> 
> This feels way too risky to me.  I think making some code do something
> different between (x & OST_DYNAMIC) == 0 and == 1 is just fine,
> it doesn't have to share everything.  After all, for __bdos we actually
> emit code to compute it at runtime, while for __bos we don't.
> So I'd keep e.g. .pass = 0, .pass = 1 and .pass = 2 (in a loop) in
> compute_builtin_object_size for non-OST_DYNAMIC and only use your new
> stuff for __bdos.
> E.g. creating new SSA_NAMEs for __bos doesn't look like a good idea to me.
> The GCC __bos testsuite is not big enough that it covers everything and
> even in it we sometimes reexamine 2, 3 or 4 times.

OK, so addr_object_size does not participate in dependency loops, so I 
can keep its changes intact and simply add a INTEGER_CST check at the 
end to return unknown if the size expression is not constant; we kinda 
do that for object offsets anyway.

I could then make a new entry point collect_object_sizes_for (renaming 
the current one to collect_static_object_sizes_for and a new one 
collect_dynamic_object_sizes_for, routing based on object_size_type & 
OST_DYNAMIC) which sends the object size collection down different 
paths.  I can reuse the object size vectors and just have different data 
in them.

Would that be reasonable?

Thanks,
Siddhesh

  reply	other threads:[~2021-11-23 13:44 UTC|newest]

Thread overview: 97+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-09 19:01 [PATCH 00/10] __builtin_dynamic_object_size Siddhesh Poyarekar
2021-11-09 19:01 ` [PATCH 01/10] tree-object-size: Replace magic numbers with enums Siddhesh Poyarekar
2021-11-19 16:00   ` Jakub Jelinek
2021-11-09 19:01 ` [PATCH 02/10] tree-object-size: Abstract object_sizes array Siddhesh Poyarekar
2021-11-19 16:18   ` Jakub Jelinek
2021-11-19 16:53     ` Siddhesh Poyarekar
2021-11-09 19:01 ` [PATCH 03/10] tree-object-size: Use tree instead of HOST_WIDE_INT Siddhesh Poyarekar
2021-11-19 17:06   ` Jakub Jelinek
2021-11-19 19:01     ` Siddhesh Poyarekar
2021-11-19 19:16       ` Jakub Jelinek
2021-11-22  8:41         ` Richard Biener
2021-11-22 10:11       ` Siddhesh Poyarekar
2021-11-22 10:31         ` Jakub Jelinek
2021-11-22 12:00           ` Siddhesh Poyarekar
2021-11-22 12:31             ` Siddhesh Poyarekar
2021-11-22 12:32               ` Jakub Jelinek
2021-11-23 11:58                 ` Jakub Jelinek
2021-11-23 13:33                   ` Siddhesh Poyarekar
2021-11-09 19:01 ` [PATCH 04/10] tree-object-size: Single pass dependency loop resolution Siddhesh Poyarekar
2021-11-23 12:07   ` Jakub Jelinek
2021-11-23 13:44     ` Siddhesh Poyarekar [this message]
2021-11-23 14:22       ` Jakub Jelinek
2021-11-09 19:01 ` [PATCH 05/10] __builtin_dynamic_object_size: Recognize builtin Siddhesh Poyarekar
2021-11-23 12:41   ` Jakub Jelinek
2021-11-23 13:53     ` Siddhesh Poyarekar
2021-11-23 14:00       ` Jakub Jelinek
2021-11-09 19:01 ` [PATCH 06/10] tree-object-size: Support dynamic sizes in conditions Siddhesh Poyarekar
2021-11-23 15:12   ` Jakub Jelinek
2021-11-23 15:36     ` Siddhesh Poyarekar
2021-11-23 15:38       ` Siddhesh Poyarekar
2021-11-23 16:17         ` Jakub Jelinek
2021-11-23 15:52       ` Jakub Jelinek
2021-11-23 16:00         ` Siddhesh Poyarekar
2021-11-23 16:19           ` Jakub Jelinek
2021-11-09 19:01 ` [PATCH 07/10] tree-object-size: Handle function parameters Siddhesh Poyarekar
2021-11-09 19:01 ` [PATCH 08/10] tree-object-size: Handle GIMPLE_CALL Siddhesh Poyarekar
2021-11-09 19:01 ` [PATCH 09/10] tree-object-size: Dynamic sizes for ADDR_EXPR Siddhesh Poyarekar
2021-11-09 19:01 ` [PATCH 10/10] tree-object-size: Handle dynamic offsets Siddhesh Poyarekar
2021-11-19 15:56 ` [PATCH 00/10] __builtin_dynamic_object_size Jakub Jelinek
2021-11-26  5:28 ` [PATCH v3 0/8] __builtin_dynamic_object_size Siddhesh Poyarekar
2021-11-26  5:28   ` [PATCH v3 1/8] tree-object-size: Replace magic numbers with enums Siddhesh Poyarekar
2021-11-26 16:46     ` Jakub Jelinek
2021-11-26 17:53       ` Siddhesh Poyarekar
2021-11-26 18:01         ` Jakub Jelinek
2021-11-26  5:28   ` [PATCH v3 2/8] tree-object-size: Abstract object_sizes array Siddhesh Poyarekar
2021-11-26 16:47     ` Jakub Jelinek
2021-11-26  5:28   ` [PATCH v3 3/8] tree-object-size: Save sizes as trees and support negative offsets Siddhesh Poyarekar
2021-11-26 16:56     ` Jakub Jelinek
2021-11-26 17:59       ` Siddhesh Poyarekar
2021-11-26 18:04         ` Jakub Jelinek
2021-11-26 18:07           ` Siddhesh Poyarekar
2021-11-26  5:28   ` [PATCH v3 4/8] __builtin_dynamic_object_size: Recognize builtin Siddhesh Poyarekar
2021-11-26  5:28   ` [PATCH v3 5/8] tree-object-size: Support dynamic sizes in conditions Siddhesh Poyarekar
2021-11-26  5:28   ` [PATCH v3 6/8] tree-object-size: Handle function parameters Siddhesh Poyarekar
2021-11-26  5:28   ` [PATCH v3 7/8] tree-object-size: Handle GIMPLE_CALL Siddhesh Poyarekar
2021-11-26  5:28   ` [PATCH v3 8/8] tree-object-size: Dynamic sizes for ADDR_EXPR Siddhesh Poyarekar
2021-11-26  5:38   ` [PATCH v3 0/8] __builtin_dynamic_object_size Siddhesh Poyarekar
2021-12-01 14:27 ` [PATCH v4 0/6] __builtin_dynamic_object_size Siddhesh Poyarekar
2021-12-01 14:27   ` [PATCH v4 1/6] tree-object-size: Use trees and support negative offsets Siddhesh Poyarekar
2021-12-15 15:21     ` Jakub Jelinek
2021-12-15 17:12       ` Siddhesh Poyarekar
2021-12-15 18:43         ` Jakub Jelinek
2021-12-16  0:41           ` Siddhesh Poyarekar
2021-12-16 15:49             ` Jakub Jelinek
2021-12-16 18:56               ` Siddhesh Poyarekar
2021-12-16 21:16                 ` Jakub Jelinek
2021-12-01 14:27   ` [PATCH v4 2/6] __builtin_dynamic_object_size: Recognize builtin Siddhesh Poyarekar
2021-12-15 15:24     ` Jakub Jelinek
2021-12-16  2:16       ` Siddhesh Poyarekar
2021-12-01 14:27   ` [PATCH v4 3/6] tree-object-size: Support dynamic sizes in conditions Siddhesh Poyarekar
2021-12-15 16:24     ` Jakub Jelinek
2021-12-15 17:56       ` Siddhesh Poyarekar
2021-12-15 18:52         ` Jakub Jelinek
2021-12-01 14:27   ` [PATCH v4 4/6] tree-object-size: Handle function parameters Siddhesh Poyarekar
2021-12-01 14:27   ` [PATCH v4 5/6] tree-object-size: Handle GIMPLE_CALL Siddhesh Poyarekar
2021-12-01 14:27   ` [PATCH v4 6/6] tree-object-size: Dynamic sizes for ADDR_EXPR Siddhesh Poyarekar
2021-12-18 12:35 ` [PATCH v5 0/4] __builtin_dynamic_object_size Siddhesh Poyarekar
2021-12-18 12:35   ` [PATCH v5 1/4] tree-object-size: Support dynamic sizes in conditions Siddhesh Poyarekar
2022-01-10 10:37     ` Jakub Jelinek
2022-01-10 23:55       ` Siddhesh Poyarekar
2021-12-18 12:35   ` [PATCH v5 2/4] tree-object-size: Handle function parameters Siddhesh Poyarekar
2022-01-10 10:50     ` Jakub Jelinek
2022-01-11  0:32       ` Siddhesh Poyarekar
2021-12-18 12:35   ` [PATCH v5 3/4] tree-object-size: Handle GIMPLE_CALL Siddhesh Poyarekar
2022-01-10 11:03     ` Jakub Jelinek
2021-12-18 12:35   ` [PATCH v5 4/4] tree-object-size: Dynamic sizes for ADDR_EXPR Siddhesh Poyarekar
2022-01-10 11:09     ` Jakub Jelinek
2022-01-04  3:24   ` [PING][PATCH v5 0/4] __builtin_dynamic_object_size Siddhesh Poyarekar
2022-01-11  8:57 ` [PATCH v6 " Siddhesh Poyarekar
2022-01-11  8:57   ` [PATCH v6 1/4] tree-object-size: Support dynamic sizes in conditions Siddhesh Poyarekar
2022-01-11  9:43     ` Jakub Jelinek
2022-01-11  9:44       ` Siddhesh Poyarekar
2022-01-11  8:57   ` [PATCH v6 2/4] tree-object-size: Handle function parameters Siddhesh Poyarekar
2022-01-11  9:44     ` Jakub Jelinek
2022-01-11  8:57   ` [PATCH v6 3/4] tree-object-size: Handle GIMPLE_CALL Siddhesh Poyarekar
2022-01-11  8:57   ` [PATCH v6 4/4] tree-object-size: Dynamic sizes for ADDR_EXPR Siddhesh Poyarekar
2022-01-11  9:47     ` Jakub Jelinek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d4327a82-c175-bbe2-2353-bc49189d301d@gotplt.org \
    --to=siddhesh@gotplt.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).