VECustomDAG's functions simplify emitting VE custom ISD nodes. The class is just a stub now. We add more functions, in particular for the VP->VVP->VE lowering, to VECustomDAG as we build up vector isel.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I have several quesions.
- What is the purpose of this CustomDAG? What is the differences from SelectionDAG.getNode()?
- Do we really need CustomDAG although all other architectures works well with SelectionDAG.
- Is it possible to extend SelectionDAG for us and probablly other vector architectures?
CustomDAG provides VE-specific functions for building and legalizing SDNodes.
In this patch, it's just a stub that fowards getNode/getConstant to the underlying DAG, which already needs less parameters.
- Do we really need CustomDAG although all other architectures works well with SelectionDAG.
CustomDAG does not replace SelectionDAG. It wraps around it and provides convenience functions. In the future, there will also be functions for VE-specific SDNodes kinds (VVP_* and VEC_*).
- Is it possible to extend SelectionDAG for us and probablly other vector architectures?
Yes. CustomDAG functions that were implemented in a VE-specific way in downstream could be generalized to be available for all VP-based backends. For example, VP_UREM expansion. Most functions in CustomDAG, however, are tailored to VE and have VE-specific lowering and architecture knowledge built in.
Please apply clang-format suggestsions.
I'm still thinking to ask other professional who knows SelectionDAG to review these modifications, since I really don't know it enough to review it... But, it is limited for only VE, so it is possible to accept it... Isn't it possible to other professionals to review this?
Please follow the patterns that can be observed in other backends - how do they deal with this problem?
If nothing else, the name is wrong, it's a bit too generic.
It's custom to have static functions in <Target>ISelLowering.cpp with the following pattern:
static SDValue get|splat|convert|createSTUFF(.. SDValue Op, SelectionDAG &DAG);
Grep for static SDValue in the targets isellowerings. This is any function that isn't directly called from LowerOperation.
We just put those functions in a class since all of them take a DAG and proceed to construct a DL from the SDValue that is lowered. I don't see how this pattern is much different from what the other backends are doing.
If nothing else, the name is wrong, it's a bit too generic.
Fair. Is VECustomDAG good?
Sorry for delay of reviewing. Please add little more explanation to a head file.
llvm/lib/Target/VE/VECustomDAG.h | ||
---|---|---|
10–11 | How about explaining this like. It's much better to work to lower expectation from the name "CustomDAG". This file defines the helper functions that VE uses to lower LLVM code into a selection DAG. For example, hiding SDLoc, and easy to use SDNodeFlags. |
Changing header comment as suggested / rebased
llvm/lib/Target/VE/VECustomDAG.h | ||
---|---|---|
10–11 | That's a good idea. I'll take your suggestion. |
How about explaining this like. It's much better to work to lower expectation from the name "CustomDAG".