On 10/25/2021 12:49 PM, Aldy Hernandez wrote:
On Mon, Oct 25, 2021 at 8:42 PM Jeff Law <jeffreya...@gmail.com> wrote:
On 10/24/2021 12:25 PM, Aldy Hernandez 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).
I can leave the simple gimple FE test since I've already coded it.
Up to you.
I'd keep the gimple FE test. I can easily see coming back to this ;-)
How does this look?
Looks good for the trunk to me.
Thanks Jeff.
I will commit the other patch from this series as well as the
testsuite change, both of which you approved. Also, I was going to
commit the following as obvious until I noticed it depended on the
other patches:
https://gcc.gnu.org/pipermail/gcc-patches/2021-October/582232.html
Just to be explicit, that patch is fine too.
I think it's now obvious, but if you have an objection, let me know.
It'll be a while, cause I need to rest everything again on x86 and
ppc64. I'm tired of getting mail from CI bots :).
Thanks for your feedback and patience.
Thanks for digging into this stuff. It's ripe for some developer love.
jeff
