[GR-52844] Add NI compiler configuration Os.

[graalvmbot]

No description provided.

[gilles-duboscq]

FYI @koutheir

[koutheir]

The clang compiler front-end handles the flag -Os by emitting the LLVM-IR attribute llvm::Attribute::OptimizeForSize on functions. When -Oz is specified instead, the following additional flags are also specified on functions: llvm::Attribute::MinSize and llvm::Attribute::NoInline.
These flags are then checked by LLVM in various places, affecting code generation.

@davleopo, does it make sense for the LLVM back-end of GraalVM to follow the same behavior of clang?

[davleopo]

@vjovanov @loicottet can you chime in here and share your thoughts - I am no expert on the clang backend

[loicottet]

The LLVM backend already specifies NoInline on all functions, since we rely on the Graal inliner. This is necessary for correctness as we need the Native Image runtime metadata to match the actual functions present in the image.
For OptimizeForSize and MinSize, it would be trivial to add them, but it might cause problems if it starts messing with some invariants that the LLVM backend relies on. We would need to try it out to be sure.

[koutheir]

@loicottet, can you elaborate on the invariants you're suspecting might be invalidated when OptimizeForSize or MinSize are specified?

[loicottet]

One thing that comes to mind is the requirement that frame headers (frame pointer and return IP) be present on the stack to enable stack crawling. My comment comes from experience in trying out LLVM compiler options since the statepoints feature that the LLVM backend uses is not a very widely used one.

[koutheir]

One thing that comes to mind is the requirement that frame headers (frame pointer and return IP) be present on the stack to enable stack crawling.

If I understand well, you're afraid that using the function attributes OptimizeForSize and MinSize may lead LLVM to disregard the llc options -no-x86-call-frame-opt, --aarch64-frame-record-on-top and --frame-pointer=all.

It's certainly possible, even though the way I understand -Os is to generate less machine instructions, not smaller stack frames. I would even find it reasonable to use more stack space, if that allows generating fewer instructions.

My comment comes from experience in trying out LLVM compiler options since the statepoints feature that the LLVM backend uses is not a very widely used one.

I agree, and LLVM still marks gc intrinsics in LLVM IR as experimental. This is in addition to the fact that support for statepoints is only implemented for some 64-bits architectures. So I also expect stuff to break due to that.

From your experience, do you think it is enough to make the GraalVM compiler aware of "optimizing for size" mode, but keep LLVM in a different optimization mode? Or do you think it is worth trying out the OptimizeForSize and MinSize function attributes?

[loicottet]

If I understand well, you're afraid that using the function attributes OptimizeForSize and MinSize may lead LLVM to disregard the llc options -no-x86-call-frame-opt, --aarch64-frame-record-on-top and --frame-pointer=all.

Not exactly, those options are examples of workarounds for issues of the same type that popped up in the past.

From your experience, do you think it is enough to make the GraalVM compiler aware of "optimizing for size" mode, but keep LLVM in a different optimization mode? Or do you think it is worth trying out the OptimizeForSize and MinSize function attributes?

I certainly think it will be interesting to try those options out. I don't think it will be enough to only set the GraalVM compiler to optimize for size, as the instruction emission is ultimately done by the LLVM compiler, which could undo some of the Graal optimizations (as it would be optimizing for performance).