[llvm-dev] Handling argument for an intrinsic

Philip Reames via llvm-dev llvm-dev at lists.llvm.org
Fri Dec 9 11:59:41 PST 2016


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.

Philip


On 12/08/2016 03:31 PM, Louis Li wrote:
> 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.
>
> https://reviews.llvm.org/D27503#58aa05e8
>
> On Fri, Dec 2, 2016 at 5:35 PM Philip Reames 
> <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote:
>
>     On 12/01/2016 04:01 PM, Louis Li via llvm-dev wrote:
>>     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!
>     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?
>>
>>     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)
>>     https://drive.google.com/file/d/0B5G4m_mQneSjRWQzRVltdDJOQnM/view?usp=sharing
>>     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)
>>     ==============
>>     +def PATCHABLE_LOG_CALL : Instruction {
>>     +  let OutOperandList = (outs);
>>     +  let InOperandList = (ins unknown:$entry);
>>     +  let AsmString = "# XRay Custom Log.";
>>     +  let usesCustomInserter = 1;
>>     +  let hasSideEffects = 1;
>>     +}
>>
>>     Example IR for the graph above
>>     ===========
>>     define i32 @caller() nounwind noinline uwtable
>>     "function-instrument"="xray-always" {
>>         %logentryptr = alloca i8
>>         call void @llvm.xray.customlog(i8* %logentryptr)
>>         ret i32 0
>>     }
>>
>>     declare void @llvm.xray.customlog(i8*)
>>
>>
>>     _______________________________________________
>>     LLVM Developers mailing list
>>     llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>>     http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161209/e6aae354/attachment.html>


More information about the llvm-dev mailing list