Hi, I’m trying to implement a target-agnostic intrinsic, first targeting X86. I’m trying to map the intrinsic SD node to an instruction with a certain target opcode that I’ve introduced. The issue that I’m running into is what the correct way to lower the argument is. I’ve done a couple loops on the docs so any help would be appreciated!
Some options I’ve explored but have been missing some crucial step/concept:
- tablegen matching?
- SelectionDAGBuilder.cpp + BuildMI call (but then this runs into the issue of lowering the argument correctly - not sure if that’s feasible at this point in instruction selection)
- X86ISelLowering – same confusion as above
Here’s how the dag currently looks (before erroring out, since I haven’t handled the intrinsic)
Would it be problematic if I somehow extracted the pointer address arg to the intrisic from TargetConstant and passed it as MachineOperand to the MachineInstruction?
Opcode definition (Target/Target.td)
I’m really confused by the way you’re asking the question. Assuming you’re adding code to SelectionDAGBuilder, handling the argument should just be a getValue(Value*) call. Take a look at the lowering for ctlz (or one of many other examples), how are your arguments different than what’s done here? Do you need to vary the psuedo op emitted depending on the argument or something like that?
Hi Philip, thanks for the response. No, I don’t need to vary the pseudo op – I did follow the other intrinsics but what happens now (after tinkering some more) is that my instruction actually gets optimized out (after debugging by showing the selection dag after various rounds of optimization). It might help if I send a patch along – I uploaded it to phabricator with a link to selectiondagbuilder.
This sounds like you have a side effecting psuedo which is not marked with the appropriate flags or a misconstructed DAG. I’d suggest using -print-after-all, find the place that’s dropping it, look at the reasoning, and use that to identify your mistake.