<div dir="ltr">On 30 June 2014 16:01, Joerg Sonnenberger <span dir="ltr"><<a href="mailto:joerg@britannica.bec.de" target="_blank">joerg@britannica.bec.de</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="">On Mon, Jun 30, 2014 at 03:04:21PM +0200, Sobczak, Janusz wrote:<br>
> On 30 June 2014 13:13, Joerg Sonnenberger <<a href="mailto:joerg@britannica.bec.de">joerg@britannica.bec.de</a>> wrote:<br>
><br>
> > On Mon, Jun 30, 2014 at 10:45:24AM +0200, Sobczak, Janusz wrote:<br>
> > > I'm thinking about modyfing __builtin_constant_p() implementation in<br>
> > clang<br>
> > > to do this (for integer arguments):<br>
> > > if (argument is known to be constant)<br>
> > >     replace  __builtin_constant_p() with 1 (True)<br>
> > > else<br>
> > >    replace __builtin_constant_p() with @llvm.is_constant() IR<br>
> ><br>
> > What is the intended use case here? All cases that *I* consider to be<br>
> > sane applications of __builtin_constant_p are workaround for target<br>
> > specific features that are better exposed as intrinsics themselve, e.g.<br>
> > IO asm instructions on x86. It is one of the most abused features of<br>
> > GCC, especially since it can introduce magic variance due to optimizer<br>
> > changes.<br>
> ><br>
><br>
> Please read the discussion here: <a href="http://llvm.org/bugs/show_bug.cgi?id=4898" target="_blank">http://llvm.org/bugs/show_bug.cgi?id=4898</a><br>
<br>
</div>I consider the original example from the Linux kernel bogus and I read<br>
the discussion as agreeing with that. I haven't yet seen an example of<br>
the performance improvements you mentioned. The whole conditions in the<br>
original example will be folded away. If they are not, that's a bug.<br>
<div class=""><div class="h5"><br></div></div></blockquote><div>What uses of _builtin_constant_p() are sensible and what uses are, in fact, abuses is an interesting topic for a discussion. Nevertheless, current status is that one can use __builtin_constant_p() in inline functions and it will work as expected when compiled with gcc but __builtin_constant_p() would always return false if compiled with clang.<br>
</div><div>This means that currently if someone wants to use __builtin_constant_p(), he needs to write macros instead of inline functions.<br><br></div><div>For example, there are function-like macros in the linux kernel like:<br>
<pre><a name="L105" href="http://lxr.free-electrons.com/source/include/uapi/linux/swab.h#L105">105</a> #define <a href="http://lxr.free-electrons.com/ident?i=__swab16">__swab16</a>(<a href="http://lxr.free-electrons.com/ident?i=x">x</a>)                             \
<a name="L106" href="http://lxr.free-electrons.com/source/include/uapi/linux/swab.h#L106">106</a>         (__builtin_constant_p((<a href="http://lxr.free-electrons.com/ident?i=__u16">__u16</a>)(<a href="http://lxr.free-electrons.com/ident?i=x">x</a>)) ?     \
<a name="L107" href="http://lxr.free-electrons.com/source/include/uapi/linux/swab.h#L107">107</a>         <a href="http://lxr.free-electrons.com/ident?i=___constant_swab16">___constant_swab16</a>(<a href="http://lxr.free-electrons.com/ident?i=x">x</a>) :                 \
<a name="L108" href="http://lxr.free-electrons.com/source/include/uapi/linux/swab.h#L108">108</a>         <a href="http://lxr.free-electrons.com/ident?i=__fswab16">__fswab16</a>(<a href="http://lxr.free-electrons.com/ident?i=x">x</a>))
<a name="L109" href="http://lxr.free-electrons.com/source/include/uapi/linux/swab.h#L109">109</a> </pre>This macro swaps the bytes at compile time if it is possible or calls arch specific, fast swab implementations if 'x' is not known to be constant (i.e. calls __builtin_swab() if compiler supports it).<br>
<br></div><div>The fewer false negatives __builtin_constant_p() returns, the more often the compile-time computation path can be taken.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class=""><div class="h5">
Joerg<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr">Janusz Sobczak<br>Mobica Ltd<br><a href="http://www.mobica.com" target="_blank">www.mobica.com</a> <<a href="http://www.mobica.com" target="_blank">http://www.mobica.com</a>><br>
<br><br>*Mobica is a provider of software engineering, testing and consultancy <br>services based in the UK, Poland and the USA, with a worldwide customer <br>base. We have a proven track record in delivering innovative solutions to <br>
some of the world’s best-known companies in a range of sectors including <br>Automotive, Mobile, Semiconductor, Finance, TV, Marine and Aviation.*<br><br></div>
</div></div>