Confusing ERROR with LoopAccessLegacyAnalysis: Pass 'Unnamed pass: implement Pass::getPassName()' is not initialized.

Dear all,

I write a new LoopPass which wants to use passes including LoopInfoWrapperPass, ScalarEvolutionWrapperPass and LoopAccessLegacyAnalysis.
Therefore, I implement the following code based on LLVM 9.0.0:


you will have to call
before you can use it as a pass dependency. This is usually done by a
sequence of

INITIALIZE_PASS_BEGIN(YourPass, "your_pass", "Your Pass Name", false, false)
INITIALIZE_PASS_END(YourPass, "your_pass", "Your Pass Name", false, false)

which also creates an initializer for your pass:
initializeYourPassPass which you should call in some way in your


Dear Michael,

Thanks a lot for your suggestion but I not sure whether it is caused by this initialization because for example, I do not do such initialization for LoopInfoWrapperPass in my code but it works fine.

I tried your solution for the pass but got the following compilation error ----> namespace “llvm” has no member “initializeLoopInformationCollectPass”.

Such error is raised from the macro define: INITIALIZE_PASS_END. Does it mean I need to specially define such function in the LLVM namespace?

Thanks again for your time and patience!

Best regards,

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 (“”, “include/clang/Sema/ParsedAttr.h” and “utils/TableGen/ClangAttrEmitter.cpp”).

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,

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.


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.


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 using ap_int = int attribute((__ap_int(bits)));

template 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.


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.


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.

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?

I put this up for review here:

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.