[RFC] Create llvm/Support/InternalLimits.h

Hello,

There are internal limits within LLVM that are fundamental to how LLVM operates but are defined in awkward places when it comes to library layering. I'd like to propose that we fix that with a simple "InternalLimits.h" file that contains a few essential constants.

For example, the maximum alignment supported by LLVM is defined by CodeGen but clang's Sema needs to know that value to enforce that users stay within bounds. That being said, clang's Sema doesn't need or want to depend on CodeGen for various good reasons.

If we create llvm/Support/InternalLimits.h and define the alignment limit there, then LLVM's CodeGen and clang's Sema can both include that file without Sema creating a dependency on CodeGen.

Thoughts?
Dave

Hello,

There are internal limits within LLVM that are fundamental to how LLVM operates but are defined in awkward places when it comes to library layering. I'd like to propose that we fix that with a simple "InternalLimits.h" file that contains a few essential constants.

For example, the maximum alignment supported by LLVM is defined by CodeGen but clang's Sema needs to know that value to enforce that users stay within bounds. That being said, clang's Sema doesn't need or want to depend on CodeGen for various good reasons.

If we create llvm/Support/InternalLimits.h and define the alignment limit there, then LLVM's CodeGen and clang's Sema can both include that file without Sema creating a dependency on CodeGen.

Thoughts?

Thank you for looking into this! I think that sounds like a reasonable approach.

~Aaron

Sounds good to me. Depending on the "limits" we might want to put it in llvm/IR/ though.
Eventually we might want to have multiple (and all included form Frontend/InternalLimits.h) but let's see.

~ Johannes

I think this is a good solution.

Sounds good to me.

Depending on the "limits" we might want to put it in
llvm/IR/ though.

... which will put us back into square 1, because this comes up
precisely because we can't include IR headers in clang sema.

Eventually we might want to have multiple (and all included form
Frontend/InternalLimits.h) but let's see.

~ Johannes

Roman

I think this is a good solution.

Sounds good to me.
Depending on the "limits" we might want to put it in
llvm/IR/ though.

... which will put us back into square 1, because this comes up
precisely because we can't include IR headers in clang sema.

I didn't realize we can't include those headers if they are self contained.

I would prefer llvm/Frontend/InternalLimits.h over Support but both seem OK.

~ Johannes

Seems like a reasonable idea, but we want to be careful to define which internal limits are in scope, and which are not.

For instance, ValueTracking has a bunch of internal scope limits for analysis purpose. Moving those into some generic location would seem like a mistake.

Your example of alignment is a good one.

As a idea, what if we specifically restricted this to internal limits of the IR representation? Or is that too narrow? What other specific limits are you thinking of?

Philip

Hi Philip,

I just wanted jump start the discussion. That’s all. And I think we should just pay as we go. Hopefully we’ll never feel the need to subdivide the file.

Dave