This is an archive of the discontinued LLVM Phabricator instance.

[IRBuilder] CreateIntrinsic with implicit mangling
ClosedPublic

Authored by foad on Jul 29 2022, 6:51 AM.

Details

Summary

Add a new IRBuilderBase::CreateIntrinsic which takes the return type and
argument values for the intrinsic call but does not take an explicit
list of types to mangle. Instead the builder works this out from the
intrinsic declaration and the types of the supplied arguments.

This means that the mangling is hidden from the client, which in turn
means that intrinsic definitions can change which arguments are mangled
without requiring any changes to the client code.

Diff Detail

Event Timeline

foad created this revision.Jul 29 2022, 6:51 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 29 2022, 6:51 AM
foad requested review of this revision.Jul 29 2022, 6:51 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 29 2022, 6:51 AM
nlopes added inline comments.Jul 29 2022, 6:53 AM
llvm/unittests/IR/IRBuilderTest.cpp
145

Please use PoisonValue::get() whenever possible. Thank you!

foad added a comment.Jul 29 2022, 6:56 AM

I created a patch to show examples of using the new API, but I'm not sure there's any good reason to commit it, so I just put it here: https://reviews.llvm.org/differential/diff/448621/

foad added inline comments.Jul 29 2022, 6:57 AM
llvm/unittests/IR/IRBuilderTest.cpp
145

You have got a Herald rule for UndefValue!

nlopes added inline comments.Jul 29 2022, 6:59 AM
llvm/unittests/IR/IRBuilderTest.cpp
145

ahah, I do indeed🤣

foad updated this revision to Diff 448622.Jul 29 2022, 7:00 AM

Use poison instead of undef.

foad added a reviewer: nikic.Jul 29 2022, 8:45 AM

I like it. It seems to me that handling varargs wouldn't be a huge effort so maybe best to already take care of it? Basically, check whether the table has at least two entries (i.e. there are arguments) and the last one is a VarArg kind. If so, truncate the ArgTys to the number of argument table entries before doing the match.

foad added a comment.Aug 1 2022, 8:14 AM

It seems to me that handling varargs wouldn't be a huge effort so maybe best to already take care of it? Basically, check whether the table has at least two entries (i.e. there are arguments) and the last one is a VarArg kind. If so, truncate the ArgTys to the number of argument table entries before doing the match.

I did try but I failed. I would need to spend some more time to understand why the interface provided by Intrinsic::matchIntrinsicVarArg works the way it does. So I would prefer to get the current patch approved first if possible.

nhaehnle accepted this revision.Aug 2 2022, 4:15 AM

Sure, seems reasonable. I assume the varargs case is currently caught by that assertion? If so, LGTM.

This revision is now accepted and ready to land.Aug 2 2022, 4:15 AM
foad added a comment.Aug 2 2022, 5:09 AM

I assume the varargs case is currently caught by that assertion?

Yes I have just double-checked that.

This revision was landed with ongoing or failed builds.Aug 2 2022, 5:21 AM
This revision was automatically updated to reflect the committed changes.