[clang] [clang][rtsan] Add sanitize_realtime_unsafe attr to [[clang::blocking]] function IR (PR #111055)

[via cfe-commits]

davidtrevelyan wrote:

> > With the function effects warnings (as errors) activated, blocking functions cannot be called from non-blocking functions, and this is enforced at compile time. The purpose of this series of PRs is to introduce similar functionality into RealtimeSanitizer, so that it can make the equivalent check at run time.
> 
> What is the reason we need to check something again at runtime that was already checked at compile-time? In case people didn't `-Werror` the warning?

Yes indeed - that's one of a few scenarios where we believe this is needed:

- the user didn't compile with `-Werror`,
- the user didn't compile with `-Wfunction-effects` (i.e. no checking at compile time happens),
- the `[[clang::blocking]]` function is called deep within the call stack of a higher-level `[[clang::nonblocking]]` function, or maybe even
- the `[[clang::blocking]]` function is pre-compiled in a different library to what the user is compiling.

RTSan differs from the performance constraints attributes in that it only flags violations that happen at run time, in contrast to flagging those that _could_ happen at compile time. In this scenario, if a `[[clang::blocking]]` call exists somewhere in the code within a `[[clang::nonblocking]]` function, rtsan does not consider it a violation until it's called. Depending on the user's needs they may consider this either good or bad - there are pros and cons to it, of course. RTSan takes an "innocent until proven guilty" approach, whereas performance constraints are more pessimistically "guilty until proven innocent" - and we think both are very useful. 

One of the design goals of the works was that these systems should be able to be used easily together, or separately, and that they should have analogous functionalities where possible. Hope that makes some sense!


https://github.com/llvm/llvm-project/pull/111055