Page MenuHomePhabricator

[PowerPC] Exploit test data class instruction for isinf/iszero

Authored by qiucf on Nov 25 2022, 1:48 AM.


Group Reviewers
Restricted Project

Since ISA 3.0, we have test data class instruction (x(s|v)tstdc(s|d|q)p) to classify a floating point value, which can be used to combine common FP classify operations like isinf or zero comparison.

Diff Detail

Event Timeline

qiucf created this revision.Nov 25 2022, 1:48 AM
Herald added a project: Restricted Project. · View Herald TranscriptNov 25 2022, 1:48 AM
qiucf requested review of this revision.Nov 25 2022, 1:48 AM
Herald added a project: Restricted Project. · View Herald TranscriptNov 25 2022, 1:48 AM

Thanks for working on this, I think it should be workable. However seems adding a new PPCISD would be preferable, like PPCISD::FP_CLASS? You can find same handling in AMDGPU arch FP_CLASS node.
With this new ISD:
1: we can leverage the table-gen to select the instruction.
2: we can do further combine
3: maybe this node can also be used for the fp class intrinsics like int_ppc_test_data_class_f and int_ppc_test_data_class_d?


Can we make these enums be ordered?


Any reason we don't handle NAN and denormal inputs?

qiucf planned changes to this revision.Dec 20 2022, 8:08 PM

Will change to a combine to IS_FPCLASS (based on D140381)

shchenz added inline comments.Dec 22 2022, 8:01 PM

I have same concern as previous patch: any reason for the nan and negdenormal/posdenormal are excluded here?

qiucf added inline comments.Dec 26 2022, 6:24 PM

isnan uses cond code SETUO against arbitary non-nan number, whose codegen is also a single fcmpu.

C std or LLVM intrinsics don't have issubnormal/isdenormal. For isnormal, the pattern is (abs(x) uge CONSTANT1) and (abs(x) olt CONSTANT2). Optimizing it in backend may be profitable, but (1) is out of scope of this patch; (2) clang will directly generate is_fpclass call in the future

qiucf added a comment.Sun, Feb 19, 9:53 PM

Gentle ping...

nemanjai requested changes to this revision.Mon, Feb 20, 7:32 AM

Actually, now that I've looked over the whole patch, it is not clear to me why this is in the PPC back end? There doesn't seem to be any PPC-specific requirements here. Why is it not OK to put the combine in DAGCombiner.cpp and if we don't want the combine to fire on all targets/subtargets, we can just add TargetLoweringInfo::shouldCombineToIsFPClass().

I've requested changes to require that either this be moved to target independent code or a justification be provided as to why this is PPC specific.


Nit: name this something like IsFABS or IsAbsVal (my preference would be the first one).

This revision now requires changes to proceed.Mon, Feb 20, 7:32 AM
qiucf abandoned this revision.Wed, Mar 8, 11:58 PM

I'd like to abandon this one since frontend change will eliminate this problem.