<html>
<head>
<base href="https://bugs.llvm.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - libclc maps fabs/floor/ceil/trunc/rint/round into llvm intrinsics directly in the header preventing using it with non-llvm backends"
href="https://bugs.llvm.org/show_bug.cgi?id=41031">41031</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>libclc maps fabs/floor/ceil/trunc/rint/round into llvm intrinsics directly in the header preventing using it with non-llvm backends
</td>
</tr>
<tr>
<th>Product</th>
<td>clang
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>enhancement
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>OpenCL
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedclangbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>anastasia.stulova@arm.com
</td>
</tr>
<tr>
<th>CC</th>
<td>anastasia.stulova@arm.com, llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>This issue was discovered while working on
<a class="bz_bug_link
bz_status_NEW "
title="NEW - Clang internal error during compilation of OpenCL C++ code"
href="show_bug.cgi?id=40778">https://bugs.llvm.org/show_bug.cgi?id=40778</a>
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
(<a href="https://clang.llvm.org/docs/UsersManual.html#opencl-header">https://clang.llvm.org/docs/UsersManual.html#opencl-header</a>).
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:
<a href="http://lists.llvm.org/pipermail/cfe-dev/2018-November/060041.html">http://lists.llvm.org/pipermail/cfe-dev/2018-November/060041.html</a></pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>