[LLVMdev] type qualifiers in LLVM

[Dan Gohman]

On Sep 7, 2012, at 1:48 PM, "Humphreys, Jonathan" <j-humphreys at ti.com> wrote:

> Still diving into LLVM…  I noticed that the LLVM type system does not represent qualifers (const, volatile, restrict).
>  
> From what I can gather,
>  - the back end cannot ignore volatile, so loads/stores are annotated as volatile when they load/store through a volatile qualified pointer.
> - const qualifiers are noted in metadata (I think)

Global variables can be const, and there are a variety of other vehicles for
const, but in general you're right.

> - top level restrict qualified function parameters are marked with a ‘noalias’ attribute

Right.

> So it appears that the restrict-ness of global/local pointers are not represented in LLVM, and thus ignored.
>  
> For example,
> {
>    int * restrict p2 = p1;
>    int * restrict q2 = q1;
>    ...
> }
>  
> Are there plans to add this (primarily to improve loop based alias analysis)?

Nothing at this time. Doing this well can be quite complex. Function call
boundaries are where alias information is often most critical, and handling
that case happens to be relatively simple, so it's a practical tradeoff.

>  
> And I’m just curious, what’s the design philosophy behind not representing qualifiers in the LLVM type system?  Were their semantics considered too language specific?

Compiler backends are only helped by qualifiers when they are reliable and
non-obvious. If you have something like pointer-to-const, it's not reliable,
because the const can be casted away, or it can be aliased by other
pointers-to-non-const. If you have a const local variable, the compiler can
easily see for itself that the variable is never reassigned in many cases.

Putting qualifiers in the type system would make it more complex. LLVM aims
for a tradeoff in which it obtains most of the benefits and also avoids most
of the complexity, by representing qualifiers only in places when it's
actually necessary, or actually likely to be helpful.

Dan