[PATCH] D70107: [VFABI] TargetLibraryInfo mappings in IR.

Wed May 13 10:17:28 PDT 2020

anna added a comment.

In D70107#2034194 <https://reviews.llvm.org/D70107#2034194>, @fpetrogalli wrote:

> >   I don't see anything preventing this from being a function attribute as well.
>
> HI @anna ,
>
> apologies in advance for the late reply.
>
> I don't think we want this. Imagine situation in which `proto.h` contains a scalar declaration `foo` marked with `#pragma ompe declare simd`. Suppose you include this header in 2 compilation units, one (`sourceA.c`) that can be compiled with `-fopenmp-simd`, and one (`sourceB.c`) that cannot be compiled with openmp - for any reason, for example because of some requirements on floating points computations. Then, you want to do some optimization that involves merging the two modules. The calls to `foo` in the IR generated from `sourceB.c` suddenly become vectorizable, which is wrong. So, overall, I think we should not attach this attribute to a function declaration.
>
> I appreciate that what I described might be a remote possibility, but if we ever end up having to deal with it, it will be quite hard to fix.
>
> Let me know if you have any question.
>
> Kind regards,
>
> Francesco

Hi! I really don't think this should be matter. The way I'm thinking of this - it  is the responsibility of the front-end to add the correct attribute, either on callsite or function. We can repurpose this attribute for other front-ends and for things other than OpenMP. For your example and in OpenMP, you have this on the callsites. Always. So, that cases you describe is handled.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D70107/new/

https://reviews.llvm.org/D70107