Should we set CFLAGS_JIT in Fedora?

Core Development
1

Hi.

Normally, when we build stuff with clang in Fedora, we set the CFLAGS environment to this (on x86_64):

-O2 -flto=thin -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS --config=/usr/lib/rpm/redhat/redhat-hardened-clang.cfg -fstack-protector-strong   -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer

Where /usr/lib/rpm/redhat/redhat-hardened-clang.cfg contains -fPIE.

I was wondering whether we should use (a subset of) the flags in CFLAGS_JIT, when we build the JIT stencils. We build Python with -O3, or -O0 for the debug build. Based on some experiments, some of the flags seem to raise AssertionErrors (like SHT_LLVM_LTO or SHT_X86_64_UNWIND in cpython/Tools/jit/_targets.py at v3.15.0a2 · python/cpython · GitHub). So, for x86_64, that leaves:

-O3 -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS --config=/usr/lib/rpm/redhat/redhat-hardened-clang.cfg -fstack-protector-strong   -m64 -march=x86-64 -mtune=generic -fstack-clash-protection -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer

And I wonder, is this something that we should do? I must admit that the stencils thing is a bit black magic for me, so I don’t know if this would work, or whether I should do it at all. I’d appreciate some advice from JIT experts – is this something we should even be touching?

Thanks.

1 Like
2

I’m not an expert in all of the flags you list, but I would lean toward not applying the full set to CFLAGS_JIT. As you’ve found, many flags are either incompatible or would be overridden (e.g., -O2 and -O3 are ignored since we hardcode -Os in _targets.py). We’ve tried to document the rationale for flag choices in the _compile function in that file. In general, I think we’ve kept things minimal, prioritizing flags that ensure good code layout without bloating the stencils.

Another aspect here is that if custom CFLAGS_JIT flags caused issues, I’m not sure that’s something we’d likely support as the stencil generation is sensitive to how code is laid out, and unexpected flags can break things in subtle ways. CFLAGS_JIT was added to support python-build-standalone needing to pass include paths to clang. Passing flags that affect code generation is a different matter, and not something we’ve tested or designed for.

That said, there are probably improvements we could make. A lot of the flag selection has been finding the right incantation to make things work, and not a lot of time (at least as of late) has been spent analyzing how individual flags impact the generated stencils. Ideally, if there are optimizations we should make, we’d make them upstream, I think.

3 Likes
3

Thanks. That’s reassuring, we won’t set this then :slight_smile:

One thing, however, that caught my eye:

When I set just CFLAGS_JIT="-O2" and nothing else, the stencils differ (compared with not setting the flags at all). I believe the user-provided flags are applied after -Os:

…and hence are not owerriden.

Should this be documented somehow as “designed for custom include paths, but passing flags that affect code generation is not supported”?

1 Like
4

Oops, yeah, you’re right, the user-specified flags do come after so in theory, you could override anything you wanted, at your own risk :smiley: .

Re. documenting, it could be worth documenting somewhere but I’m not sure where the correct place would be.

5

Bellow 3. Configure Python — Python 3.15.0a2 documentation ?