[llvm-bugs] [Bug 41031] New: libclc maps fabs/floor/ceil/trunc/rint/round into llvm intrinsics directly in the header preventing using it with non-llvm backends

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=41031

            Bug ID: 41031
           Summary: libclc maps fabs/floor/ceil/trunc/rint/round into llvm
                    intrinsics directly in the header preventing using it
                    with non-llvm backends
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: OpenCL
          Assignee: unassignedclangbugs at nondot.org
          Reporter: anastasia.stulova at arm.com
                CC: anastasia.stulova at arm.com, llvm-bugs at lists.llvm.org

This issue was discovered while working on
https://bugs.llvm.org/show_bug.cgi?id=40778

I was unable to translate the IR file (generated for spir target) using
SPIRV-LLVM translator because it fails when discovering llvm.fabs or
llvm.floor.

Any CL file that has the following:

#include <clc/clc.h>

float foo(float x){
 return fabs(x);
}

would be generated with llvm.abs in IR.

I was wondering if it would be possible to keep fabs as a regular function in
the header and define fabs as a call into _clc_fabs in the libraries. libclc
has always been part of LLVM and I understand why some LLVM specific lowering
might occur early. But however this change seems to be simple enough and
doesn't have much negative impact. It would help application developers with
code portability to different targets.

Alternatively, I was just thinking (may be it needs a separate discussion on
cfe-dev or so) would it be possible to just use Clang default header
(https://clang.llvm.org/docs/UsersManual.html#opencl-header).

Some advantages I see:
- Simplified flow for application developers where they don't have to modify
their code when targeting different architectures.
- Using common header will allow us to catch common bugs and reduce work
duplication when adding new features.
- Clang header can be included implicitly w/o the need for #include (required
by the spec).
- We plan to address the issue with the parsing time very soon using TableGen
techniques, see RFC:
http://lists.llvm.org/pipermail/cfe-dev/2018-November/060041.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20190311/df188b65/attachment.html>