You could work around this by creating a custom ISD node, e.g.
MyTargetISD::MyLSHR, with the same type as the general ISD::LSHR. This
custom node will then be ignored by the generic DAGCombiner. Convert
ISD::LSHR to MyTargetISD::MyLSHR in DAGCombine, optimise it as you see fit,
convert it back or lower it directly.
I've done this for ISD::CONCAT_VECTORS to avoid an inconvenient conversion
to ISD::BUILD_VECTOR. This looks a bit hacky though. I'll watch with
interest for a more idiomatic solution.
Why not just create a backend pass to clean this up? Pattern shouldn’t be too complicated to recognize in MI via use-def. Compartmentalized and you don’t have to touch core code.
That’s interesting. What’s the MI equivalent of the work list algorithm implemented by dag combine?
In particular, I like that localised improvements to the dag are composed automatically and reasonably efficiently. I don’t know how to achieve composition of back end passes beyond repeatedly applying the same sequence.
Your comment about core code is lost on me though, extra isd nodes and the performDAGCombine hook have been sufficient so far.
I agree. The comment about core code was just a generalization. It was just an alternative to a DAG solution for Vivek.