Re: [PATCH] Try to resolve paths in threader without looking further back.

[Aldy Hernandez <aldyh@redhat.com>]

On Sun, Oct 24, 2021 at 8:25 PM Aldy Hernandez <aldyh@redhat.com> wrote:
>
> On 10/24/21 6:57 PM, Jeff Law wrote:
>
> >> Ughhhh....we could put the test back, check for some random large
> >> number, and come up with a more satisfactory test later? ;-)
> > I thought our "counting" based tests could only check equality (ie,
> > expect to see this string precisely N times).  Though if we could check
> > that # threads realized was > some low water mark, that'd probably be
> > better than what we've got right now.
>
> Andrew actually had a patch for a dejagnu construct doing just that
> (scan-tree-dump-minimum), but I just noticed it didn't work quite right
> for this test.
>
> This is a bit embarrassing, but upon further analysis I've just noticed
> that the number of threadable candidates has been exploding over the
> year, but the ones that actually make it past the block copier
> restrictions plus rewire_first_differing_edge, etc, only changed by 1
> with this patch.  So perhaps we don't need to bend over backward (just
> yet anyhow).

For the record, the differing thread is expected and correct.

Before the patch we have these 3 threads:

[59] Registering jump thread: (6, 10) incoming edge; (10, 32) normal
(32, 33) normal (33, 36) nocopy;
[60] Registering jump thread: (7, 10) incoming edge; (10, 32) normal
(32, 33) normal (33, 36) nocopy;
[61] Registering jump thread: (8, 10) incoming edge; (10, 32) normal
(32, 33) normal (33, 36) nocopy;

Whereas with the new patch, we don't need to go as far back to thread:

[59] Registering jump thread: (10, 32) incoming edge; (32, 33) normal
(33, 36) nocopy;

Aldy