With a similar reason as D148023; some applications make heavy use of
the CRC32 intrinsic (e.g., as part of a hash function) and therefore
benefit from avoiding frequent SelectionDAG fallbacks. In our
application, we get a 2% compile-time improvement.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Note that I'm not entirely happy with duplicating the test cases; changing the existing cases in arm64-crc32.ll could also work, but currently generates an extra uxtb/uxth with FastISel. Let me know what you think.
There's been very little development of AArch64 FastISel recently because we've turned on GlobalISel by default for AArch64. Is there some reason you're not using it? Or are you getting globalisel fallbacks so frequently that hacking fastisel is somehow worthwhile?
We care a lot about compile times and in our application, GlobalISel (when it succeeds, about 10% fallback rate) increases compile times by ~50% compared to FastISel. We do plan to look at GlobalISel performance at some point, but it seems like there's a lot of work to be done to bring it at least on-par with FastISel wrt. compile times.
Okay. I'm bringing it up because I'd like to make sure fastisel remains limited in scope; we don't have all the GlobalISel infrastructure, so reviewing any additions is significantly more work. (For comparison, globalisel supports these intrinsics with zero globalisel-specific lines of code.)
llvm/lib/Target/AArch64/AArch64FastISel.cpp | ||
---|---|---|
3802 | You can assume intrinsics have the type declared in IntrinsicsAArch64.td; I don't think checking the type is legal does anything here. | |
3841 | I'm pretty sure fastEmitInst_rr can't fail, so there isn't any reason to null-check the return value. Is this pattern copied from somewhere? |
I totally understand, and I don't plan further substantial additions (but crc32 and struct returns are fairly important for us).
llvm/lib/Target/AArch64/AArch64FastISel.cpp | ||
---|---|---|
3841 | I probably slightly mixed this up with fastEmit_* which can fail (see sqrt intrinsic) and two occurences of fastEmitInst have checks (selectSDiv)/assertions (Intrinsic::frameaddress). |
You can assume intrinsics have the type declared in IntrinsicsAArch64.td; I don't think checking the type is legal does anything here.