https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113249
--- Comment #2 from Edwin Lu <ewlu at rivosinc dot com> --- (In reply to Robin Dapp from comment #1) > Yes, several (most?) of those are expected because the tests rely on the > default latency model. One option is to hard code the tune in those tests. > On the other hand the dump tests checking for a more or less optimal code > sequence (under certain conditions and regardless of uarch of course) and > deviation from that sequence might also indicate sub-optimal code. I > commented on this a bit when first introducing generic-ooo. > One of the reasons I've been testing things with generic-ooo is because generic-ooo had initial vector pipelines defined. For cleaning up the scheduler, I copied over the generic-ooo pipelines into generic and sifive-7 md files. As you mentioned, the scan dump fails are likely less optimal code sequences for the as a result of the cost model. I'm planning on sending up a patch in my series that adds -fno-schedule-insns -fno-schedule-insns2 to the dump scan tests that fail but do you think it would be better to hard code the tune instead? > If there are new execution failures that would be more concerning and > indicate a real bug. I've gone through a few of the differences between rocket and generic-ooo and found PR113248 which Pan helped fix. I'm not familiar enough with rvv to be able to identify if there's a bug hidden in the assembly though.
