[llvm-dev] Add Bitwidth Attribute in Clang without Modification in Source Code of Clang

Sat Mar 16 01:13:31 PDT 2019

I'm interested in see this extension in clang. Maybe in the future we can
also have custom floating-point sizes for the signficand and exponent as
well?

Are you planning to submit the patch anytime soon?

Em seg, 4 de mar de 2019 às 14:28, Keane, Erich via llvm-dev <
llvm-dev at lists.llvm.org> escreveu:

> I’ve actually got an implementation of this as an arbitrary precision
> integer extension that I’ve written up an RFC for (but not submitted).
> Below is my copy/pasted RFC (again, not reviewed, but I DO have an
> implementation of it that I need to prepare for review).  I suspect my
> implementation will do what you need out of it.  Its actually more
> significant than just adding a normal attribute.
>
>
>
>
>
>
>
>
>
> *Introduction*
>
> As we all know, LLVM-IR supports arbitrary precision integers via the iN
> syntax.  Integers that aren’t powers-of-two aren’t particularly
> interesting/useful on most hardware however, so this functionality isn’t
> typically used, and in fact, Clang does not have such support.  However,
> certain architectures DO exist where the ability to express these values
> (and do math without promotion to full integers) is valuable from a
> performance perspective, since these values can be expressed more
> efficiently in hardware.
>
>
>
> I’ve developed a solution to expose these types in clang, and am proposing
> to contribute it back to the Clang community if it is sufficiently
> acceptable to the group.  As rebasing/refactoring for the open-source
> version of clang is a significant effort, I’d like to get feedback on the
> concept and approach before putting in this effort.
>
>
>
> *Syntax*
>
> The syntax I’d chosen for this was as a Typedef Attribute.  This permits
> the consumer to define various ways to expose this functionality in their
> code.  Additionally, we’ve limited it to int/unsigned typedefs only for
> simplicity’s sake. The code looks something like:
>
>
>
> // Typical way to expose this in C:
>
> typedef int __attribute__((__ap_int(3))) ap_int3;
>
> typedef unsigned __attribute__((__ap_int(3))) ap_uint3;
>
>
>
> // Better way to expose it in modern C++:
>
> template<unsigned bits> using ap_int = int __attribute__((__ap_int(bits)));
>
> template<unsigned bits> using ap_uint = unsigned
> __attribute__((__ap_int(bits)));
>
>
>
> For our usages, we just wrapped these in a type that would better express
> the further configurable semantics, but I suspect these are useful in their
> own right.
>
>
>
> *Conversions/Promotions*
>
> We consider conversions to/from integers integral promotions that follow
> normal conversion rules, and bool conversions are also supported (just like
> integers).   AP-Int math is done at the size of the largest operand in
> order to be consistent with C rules as best as possible.  Conversions
> to/from integers and literals happen consistently with the other integer
> types.
>
>
>
> *Size/Align*
>
> One important consideration that was made is how size/alignment is
> expressed in the language.  Sizeof, for example works exclusively on bytes,
> so an ap_int<13> couldn’t be directly expressed.  Alignments are required
> to be a power-of-two, otherwise they are not expressable on some hardware.
> In implementation, we chose to use the next largest alignment (up to 64
> bits).  Additionally, for the sake of the standard library (and common
> array patterns), we were required to make sizeof also round up to the next
> power of two.  This is most consistent with what a majority of LLVM
> backends will do (for example, an ap_int<24> will be expressed as a int-32
> on most platforms), and was required to make common array patterns work.
> Unfortuantely, this results in arrays on these platforms having ‘padding’
> bits, but there isn’t really a way around that.
>
>
>
> So, is this something that the clang community is interested in?  I’ll of
> course expect extensive review through phabricator once it is ready, but
> I’d like to gauge interest (as well as determine if there is any “over my
> dead body” comments) before putting in the significant additional effort.
>
>
>
>
>
>
>
> *From:* llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] *On Behalf Of *Tingyuan
> LIANG via llvm-dev
> *Sent:* Sunday, March 3, 2019 4:48 AM
> *To:* llvm-dev at lists.llvm.org
> *Subject:* [llvm-dev] Add Bitwidth Attribute in Clang without
> Modification in Source Code of Clang
>
>
>
> Hi all,
>
>
>
>     I am handling some arbitrary precision integers (e.g. 13-bit) in the
> source code with Clang. Temporary, I declare them as structs like:
>
>
>
>               struct APINT13 VarA;
>
>
>
>     and during parsing the AST and generating IR, I transform the type of
> these variables into arbitrary precision integers.
>
>     I read some other documentations and find that adding attributes for
> variables could be a nicer way to handle arbitrary precision integer.
>
>     However, as default, there is no such attribute as "bitwidth" in
> Clang. I found the following link and get some hints but the instructions
> listed in the website require me to modify the source code of Clang
> ("Attr.td", "include/clang/Sema/ParsedAttr.h" and
> "utils/TableGen/ClangAttrEmitter.cpp").
>
>
>
>
> http://clang.llvm.org/docs/InternalsManual.html#how-to-add-an-attribute
>
>
>
>     I just wonder whether there is any way to add attributes like plugins
> without touching the source code of Clang, because to rebuild Clang could
> be time-consuming. As I know, LLVM passes can work as plugins and I guess
> there could be the similar way to handle attribute addition with Clang.
>
>     Thanks in advance for your time and suggestion! \^_^/
>
>
>
> Best regards,
>
> ------------------------------------------
>
> Tingyuan LIANG
>
> MPhil Student
>
> Department of Electronic and Computer Engineering
>
> The Hong Kong University of Science and Technology
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

-- 

Mikhail Ramalho.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190316/5331d296/attachment-0001.html>