llvm dev - Mar 2019 - Add Bitwidth Attribute in Clang without Modification in Source Code of Clang

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190304/61294808/attachment.html>

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>

I put this up for review here: https://reviews.llvm.org/D59105

Based on the feedback from Richard Smith, my next step is going to be to submit
this to WG14.

As far as floating-point sizes, it was considered but requires changes to
LLVM-IR, which would have to be done gingerly.

From: Mikhail Ramalho [mailto:mikhail.ramalho at gmail.com]
Sent: Saturday, March 16, 2019 1:14 AM
To: Keane, Erich <erich.keane at intel.com>
Cc: llvm-dev <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] Add Bitwidth Attribute in Clang without Modification in
Source Code of Clang

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<mailto: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<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<mailto: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<mailto: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/20190318/f5dc1a3d/attachment.html>