[PATCH] D35522: Move Runtime libcall definitions to a .def file

[Derek Schuff via llvm-commits]

Yeah, I was just looking into Optional (didn't see your reply until just
now), and I do think it's a better option, so to speak. I think you have it
right, most callers call it on a specific intrinsic that they know should
be available. And then in a few cases it probes to see if a particular
libcall or which of set of libcalls is available and has a fallback.

On Fri, Jul 21, 2017 at 10:15 AM David Blaikie <dblaikie at gmail.com> wrote:

> On Fri, Jul 21, 2017 at 10:10 AM Derek Schuff via Phabricator <
> reviews at reviews.llvm.org> wrote:
>
>> dschuff added a comment.
>>
>> Actually, maybe an even better idea:
>> `getLibcallName()` returns a StringRef and asserts rather than returning
>> a failure code. `getLIbcallNameIfAvailable()` returns an
>> Expected<StringRef> and can fail.
>>
>
> Probably still Optional<StringRef>, I would imagine - it doesn't have
> quite the 'security' of Expected<StringRef>, but there's not likely any
> Error that really needs to/can be communicated here, merely the absence of
> a result.
>
>
>> The former matches  90% of the existing uses. This would let us move away
>> from char* for the external symbol APIs (assuming that's a good thing) but
>> most of the existing uses wouldn't need to actually change, and those that
>> check failure would still be simple.
>>
>
> Why do so many users effectively assert on the name? There's a particular
> condition/context that they call it on that means they'll never be calling
> it on one of these libcalls that doesn't have a name?
>
> - Dave
>
>
>>
>>
>> Repository:
>>   rL LLVM
>>
>> https://reviews.llvm.org/D35522
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170721/d9592493/attachment.html>