Out-of-source subclassses vs. LLVM's RTTI system

Hi all,

Is there a good way to add out-of-LLVM-source subclasses, without modifying the corresponding in-source “Kind” enumeration?

As I play around with writing an AA pass, I’d like a good way to issue warnings for cases where my AA pass can’t handle a particular IR construct. I was thinking to report those warnings via llvm::LLVMContext::diagnose( const DiagnosticInfo & DI ). None of the existing subclasses of DiangosticInfo seems quite appropriate for my needs, so I wanted to create my own subclass, outside of the LLVM source.

So I’m stuck between (a) wanting all of my code to reside outside of the LLVM source, and (b) being obligated (I think) to modify the DiagnosticKind enum.

Thanks, Christian

Maybe have a look at Polly's lib/Analysis/ScopDetectionDiagnostic.cpp and lib/Analysis/ScopDetection.cpp. We use LLVM's diagnostics in a loadable module without modifying LLVM's DiagnosticKind enum.


Hi Tobias

Actually, I see an additional problem as well. Even if I did manage to create my own out-of-source subclass of DiagnosticInfoOptimizationBase, there’s still the question of how it would handle “Remark” severity.

To be consistent with the rest of the diagnostic classes, my subclass’s isEnabled method should probably consult the PassRemarksAnalysisOptLoc object when handling a message with severity = “remark”. Unfortunately the PassRemarksAnalysisOptLoc object has static linkage, so my code can’t easily access it.

The only way I can think to query it is to creaet a throw-away instance of some subclass of DiagnosticInfoOptimizationBase, and to provide that dummy’s constructor with the same pass name that was provided to my class’s constructor. Then I could call that dummy instance’s “isEnabled” method to find out whether or not my own code should emit the message.

Unless someone has a cleaner way to do this, I think I’ll just accept that the DiagnosticInfo stuff isn’t designed for my use case, and move on.

Sorry, I am a little in a rush, but did you see the getNextAvailablePluginDiagnosticKind() method. This should allow you to define your own DiagnosticKinds. I am not sure if this is sufficient for you, but in general the diagnostic infrastructure is supposed to be useable from plugins. It may happen that some features don't work currently, but I don't see a reason why we would not want to add/expose missing functionality in case the need arises.


Thanks! I hadn't noticed the existence of
getNextAvailablePluginDiagnosticKind(). That definitely solves one of my
problems. Thanks very much for that.

- Christian