arsenm added inline comments.
================
Comment at: clang/lib/Headers/opencl-c-base.h:832
+
+inline float __ovld __cnfn sqrt(float __x) {
+ return __builtin_elementwise_sqrt(__x);
----------------
Anastasia wrote:
> arsenm wrote:
> > svenvh wrote:
> > > Anastasia wrote:
> > > > Is this a generic implementation enough? Would some targets not need to
> > > > do something different for this built-in?
> > > >
> > > > Ideally this header is to be kept light so I am a bit worried about
> > > > adding definitions of the functions here. Otherwise we will end up in
> > > > the same situation as we one day were with opencl-c.h. So could these
> > > > be left there instead? It might be good to check with @svenvh if
> > > > TableGen header has already a way to do this function forwarding or can
> > > > be extended to do such a thing. Then it would be implementable in the
> > > > both header mechanisms. I don't know if Sven has some other ideas or
> > > > opinions...
> > > We did already discuss this a bit on the GitHub issue:
> > > https://github.com/llvm/llvm-project/issues/64264
> > As I mentioned on the ticket, it's only this one case so I'm not worried
> > about adding a lot more to the base header. I think we can start by
> > assuming llvm.sqrt always works correctly, I don't want to add more
> > complexity to handle this case without a specific reason
> > As I mentioned on the ticket, it's only this one case so I'm not worried
> > about adding a lot more to the base header.
>
> This is how things normally start. Someone else might want to continue this
> approach because it is already there.
>
> >I think we can start by assuming llvm.sqrt always works correctly, I don't
> >want to add more complexity to handle this case without a specific reason
>
> Do you mean it would apply to all implementations? What I am missing here is
> why it is required to be in the headers? Is this because it needs to be
> inlined or is it because the compiler must see `__builtin_elementwise_sqrt`
> with the surrounding code where it is called from?
Yes, I would expect any llvm consumer to correctly lower llvm.sqrt, and such an
implementation would be correctly rounded and pass conformance with
-cl-fp32-correctly-rounded-divide-sqrt
The goal is to get !fpmath attached to an llvm.sqrt call. The way this
currently happens is based on the language, it gets emitted from the various
__builtin_sqrt* calls
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D156743/new/
https://reviews.llvm.org/D156743
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
