[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