Also, are any instruction selection tests being added for Turboshaft? Something like the equivalent of test/unittests/compiler/arm64/instruction-selector-arm64-unittest.cc?
On Wednesday, November 8, 2023 at 1:26:12 PM UTC Sam Parker-Haynes wrote: > EDIT: only passes with --no-turboshaft > > On Wednesday, November 8, 2023 at 1:20:03 PM UTC Sam Parker-Haynes wrote: > >> Hi Matthias, >> >> Ah, I hadn't seen that, so yes I've been tweaking the OG selector >> function for arm64. On the x64 side of things, everything is fine with >> 'pure' turboshaft pipeline but, as with my arm64 checkout, the issue arises >> when modifying the turbofan selector function and using ---no-turboshaft. >> >> So, I guess the problem is with the RecreateSchedule? >> >> Thanks, >> Sam >> >> On Wednesday, November 8, 2023 at 1:12:56 PM UTC mlie...@google.com >> wrote: >> >>> Hi Sam, >>> >>> I don't have any insights on x64 for VisitWordCompareZero but as a quick >>> note, the TurboshaftAdapter instruction selection implementation for >>> VisitWordCompareZero for arm64 was just added yesterday by me ( >>> https://chromium-review.googlesource.com/c/v8/v8/+/5002003). >>> >>> So, just to clarify, I assume you are talking about the Turbofan {Node* >>> / TurbofanAdapter} based instruction selection with Turboshaft >>> optimizations followed by a RecreateSchedule? >>> If you do changes for the TurbofanAdapter instruction selection on arm64 >>> for code that already has an implementation for the TurboshaftAdapter, >>> could you add a TODO(mliedtke) on the Turboshaft implementation with some >>> nice description and CC me on the gerrit changes, so these don't get lost >>> when we switch over to the TurboshaftAdapter? >>> >>> Thanks and best regards, >>> Matthias >>> >>> On Wed, Nov 8, 2023 at 1:54 PM Sam Parker-Haynes <sam.p...@arm.com> >>> wrote: >>> >>>> Hi, >>>> >>>> I've been investigating rematerialising flag setting instructions in >>>> VisitWordCompareZero, just by removing the CanCover check, and something >>>> is >>>> going wrong with turboshaft. >>>> >>>> I have an arithmetic overflow operation, Int32AddWithOverflow, and the >>>> overflow check is used by two branch operations. With a turbofan-only >>>> flow, >>>> the overflow operation and the projection will be duplicated for the >>>> second >>>> branch, and everything is fine. But with turboshaft, neither the overflow >>>> operation or projection are duplicated and the second branch uses the >>>> original projection[1] value. This looks fine at the IR level, but ends up >>>> broken after isel when the register allocator comes across a virtual >>>> register without a definition. This happens for both x64 and arm64, so I'm >>>> assuming turboshaft is making some assumptions, based on the current >>>> behaviour, that are non-obvious to me. >>>> >>>> Any ideas? >>>> >>>> Thanks! >>>> Sam >>>> >>>> >>>> >>>> -- >>>> -- >>>> v8-dev mailing list >>>> v8-...@googlegroups.com >>>> http://groups.google.com/group/v8-dev >>>> --- >>>> You received this message because you are subscribed to the Google >>>> Groups "v8-dev" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to v8-dev+un...@googlegroups.com. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/v8-dev/175a4ba2-9d33-45bb-84e3-91d41a722846n%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/v8-dev/175a4ba2-9d33-45bb-84e3-91d41a722846n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- -- v8-dev mailing list v8-dev@googlegroups.com http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/2ccceebe-c4f5-435b-9155-a0d750503a02n%40googlegroups.com.
