[llvm-dev] Is every intrinsic norecurse?

[Daniel Berlin via llvm-dev]

On Wed, Oct 25, 2017 at 8:04 PM, Hal Finkel <hfinkel at anl.gov> wrote:

>
> On 10/20/2017 12:36 AM, Daniel Berlin via llvm-dev wrote:
>
>
>
> On Thu, Oct 19, 2017 at 10:23 PM, Mikael Holmén via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi,
>>
>> Also, I think there is a bigger problem lurking than just with norecurse.
>
> Yes
>
>
>> I think that in general, functionattrs is not very good with attributes
>> when intrinsics are present.
>>
>
>
>>
>> E.g.
>> https://bugs.llvm.org/show_bug.cgi?id=34696
>>
>> Here dbg.value prevents both norecurse and readnone from being deduced.
>>
>
> A lot of these are the more general issue of intrinsics not being marked
> with proper memory attributes as a form of attempted control
> dependence/optimization blocking/etc
>
> Intrinsics.td even says this.
>
>
>> So, it would be nice to fix this for norecurse, but it would be even
>> nicer to fix it for intrinsics and attributes in general.
>>
>
> Nobody as of yet has signed up to fix this, because it often requires
> significant thinking about each intrinsic and what really should be
> happening to it, modeling that, and teaching optimizers to deal with it.
>
> Instead the large hammer is chosen.
>
> Eventually it'll matter enough to performance for someone to do the work :)
>
>
> I agree with this, but I also agree with Sanjoy: We should add a NoRecurse
> property and mark intrinsics with it. This fits our general scheme for
> intrinsics (i.e., "if we say nothing, we assume the worst").
>
> The fact that we model all sorts of dependencies as memory dependencies is
> also a problem, but a somewhat independent one.
>
> I'm with you 100%, I was just responding to the "we should fix everything"
part.

We *should* fix everything.
But we don't have to do that here, we can start with just adding NoRecurse.
We lose nothing, and gain something.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171025/46a53e39/attachment.html>