# Julia Pragma Macros **URL:** \ **Category:** Internals & Design\ **Created:** [February 21, 2024, 5:37pm UTC](https://discourse.julialang.org/t/julia-pragma-macros/110532 "2024-02-21T17:37:54Z")\ **Posts on this page:** 5\ **Page:** 1

**Author:** ![mnemnion](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mnemnion/32/206596_2.png) [@mnemnion](https://discourse.julialang.org/u/mnemnion)\ **Post date:** [February 21, 2024, 5:37pm UTC](https://discourse.julialang.org/t/julia-pragma-macros/110532/1 "2024-02-21T17:37:54Z")

Continuing the discussion from [Ifelse vs ternary with tuples](https://discourse.julialang.org/t/ifelse-vs-ternary-with-tuples/110423/6): > [@Ifelse vs ternary with tuples](https://discourse.julialang.org/t/ifelse-vs-ternary-with-tuples/110423/6): > > Would be nice if we had a way to tell the compiler “no really, I do want this particular code to be branchless!” without using a hammer that impacts all code like that `ENV` variable. Julia has a few “pragma macros” already and I agree more would be nice. The current collection, such as `@inline` and `@inbounds/@boundscheck`, focus on compiler hints/directives, and `@nobranch` would be a good addition to that. I’ve seen some issues suggesting that there’s active work on making the compiler more “pluggable” such that this sort of thing could be provided on a package basis. I’d love to see a collection of these which function as guarantees of behavior, such that they throw compiler errors if the pragma can’t apply. Things like `@typestable` as a method annotation, `@jumptable` for a chained if-statement which throws an error if that chain can’t be turned into a switch or computed goto, and an annotation for array/vector types which asserts that they’ll be composed of the data, no pointers (don’t have a great name for this one, `@referencefree` can probably be improved upon). `@allocationlimit 5` throws an error if that number of allocations is exceeded, I think that should be possible to determine during codegen, at least if we define “compiler can’t put a number on allocations” as failing the test. Getting Julia to exhibit systems-level performance is a bit of an art form, which it kinda has to be, and it’s a strength of the language that it will do what you ask even when it can’t emit optimal machine code. A consequence of this is that tuned-up code is somewhat fragile to any changes. That’s inherent to the language design space Julia occupies, and it would be nice to have more language-level support for turning performance regressions into errors. Some of what I want here, maybe all of it, would be easier to provide as an ergonomic set of macros intended for the test suite. Not _better_ imho, the best place to assert that a method is type stable is in the definition of that method, but it would do the job just fine, and I could see it avoiding some compile-time knowledge problems to do it that way. ---

**Author:** ![SteffenPL](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/steffenpl/32/206270_2.png) [@SteffenPL](https://discourse.julialang.org/u/SteffenPL)\ **Post date:** [February 21, 2024, 6:31pm UTC](https://discourse.julialang.org/t/julia-pragma-macros/110532/2 "2024-02-21T18:31:37Z")

You might like [GitHub - JuliaLang/AllocCheck.jl: AllocCheck](https://github.com/JuliaLang/AllocCheck.jl) ---

**Author:** ![carstenbauer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/carstenbauer/32/4981_2.png) [@carstenbauer](https://discourse.julialang.org/u/carstenbauer)\ **Post date:** [February 21, 2024, 6:38pm UTC](https://discourse.julialang.org/t/julia-pragma-macros/110532/3 "2024-02-21T18:38:58Z")

FWIW, [GitHub - JuliaSIMD/LLVMLoopInfo.jl: Pass loop info to LLVM](https://github.com/JuliaSIMD/LLVMLoopInfo.jl) ---

**Author:** ![Elrod](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/elrod/32/22461_2.png) [@Elrod](https://discourse.julialang.org/u/Elrod)\ **Post date:** [February 21, 2024, 7:13pm UTC](https://discourse.julialang.org/t/julia-pragma-macros/110532/4 "2024-02-21T19:13:28Z")

For the `ifelse` vs branches example, it will be possible to pass `!unpredictable` hints to LLVM once we upgrade to LLVM 17, at least via `llvmcall`s, e.g. [FindFirstFunctions.jl/src/FindFirstFunctions.jl at 38b267e7ee2300be553830279943cba8eff7ff1d · SciML/FindFirstFunctions.jl · GitHub](https://github.com/SciML/FindFirstFunctions.jl/blob/38b267e7ee2300be553830279943cba8eff7ff1d/src/FindFirstFunctions.jl#L98) Note: I haven’t tested this yet. ---

**Author:** ![mnemnion](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mnemnion/32/206596_2.png) [@mnemnion](https://discourse.julialang.org/u/mnemnion)\ **Post date:** [February 21, 2024, 7:33pm UTC](https://discourse.julialang.org/t/julia-pragma-macros/110532/5 "2024-02-21T19:33:22Z")

> [@SteffenPL](#): > > You might like [GitHub - JuliaLang/AllocCheck.jl: AllocCheck](https://github.com/JuliaLang/AllocCheck.jl) Similar to what I had in mind, yes. It looks like everything is there to add the option for the limit to be some other number than zero. The difference is that this is something you’d annotate with to see if there are no allocations. Wouldn’t want to leave it there because it wraps the function and checks at runtime. I’m hoping that the work on refining the compiler will allow more cases where the macro inserts some [metadata](https://docs.julialang.org/en/v1/devdocs/meta/) so that codegen can use it. That would allow for a compile-time fail rather than runtime, and more importantly, passing the check would have no impact on the generated code, it would be a static guarantee that allocations don’t happen or stay below a defined boundary. I didn’t find the issue relating to this, but there’s one that indicates in-progress work on the compiler to enable more of this sort of thing, which is excellent, more ability to affect compiler internals from a package is less things which have to be built in to the language.