On Sun, Oct 24, 2021 at 8:25 PM Aldy Hernandez <al...@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
