[PATCH] D61627: [clang driver] Allow -fembed-bitcode combined with -mno-red-zone

wanders abandoned this revision. wanders added a comment. I might revisit this later. But carrying this patch locally for now. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D61627/new/ https://reviews.llvm.org/D61627

[PATCH] D61627: [clang driver] Allow -fembed-bitcode combined with -mno-red-zone

steven_wu added a comment. In D61627#1497919 , @wanders wrote: > > Why are you interested in expending this list? > > I have a (kernel) that is compiled with `-mno-red-zone` and `-mcmodel=large` > which I want to compile with `-fembed-bitcode` for a

[PATCH] D61627: [clang driver] Allow -fembed-bitcode combined with -mno-red-zone

wanders added a comment. > Why are you interested in expending this list? I have a (kernel) that is compiled with `-mno-red-zone` and `-mcmodel=large` which I want to compile with `-fembed-bitcode` for a debugging tool that needs the bitcode. But I can carry these patches locally for now.

[PATCH] D61627: [clang driver] Allow -fembed-bitcode combined with -mno-red-zone

steven_wu added a comment. Like I said, I am not worried that -mno-red-zone itself changes the ABI. As long as LLVM still respect the attribute the same way, it is fine. I want to consult Tim to make sure we can support re-targeting no red zone from armv7k to arm64_32. The intention for the

[PATCH] D61627: [clang driver] Allow -fembed-bitcode combined with -mno-red-zone

wanders added a comment. But running code that has been compiled with `-mno-red-zone` on a platform that guarantees that redzones are not stamped on should be fine as far as I can understand? The red zone is that the platform guarantees that it (e.g signal handlers, interrupts) will not use

[PATCH] D61627: [clang driver] Allow -fembed-bitcode combined with -mno-red-zone

compnerd added a comment. Well, Apple's ARM64 ABI also has red zones and they are similar to x64 in the sense that they can be used for spilling locals. I believe that the ILP32 variant retains the red zones as well, so, yes, this would impact the ABI unfortunately, and the platform

[PATCH] D61627: [clang driver] Allow -fembed-bitcode combined with -mno-red-zone

steven_wu added a comment. In D61627#1493674 , @compnerd wrote: > @steven_wu - yeah, `-mred-zone`, `-mno-red-zone` does impact the ABI, at > least on x86_64. It changes the way that the arguments are spilled and the > stack layout. Well, I am not

[PATCH] D61627: [clang driver] Allow -fembed-bitcode combined with -mno-red-zone

compnerd added a comment. @steven_wu - yeah, `-mred-zone`, `-mno-red-zone` does impact the ABI, at least on x86_64. It changes the way that the arguments are spilled and the stack layout. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D61627/new/

[PATCH] D61627: [clang driver] Allow -fembed-bitcode combined with -mno-red-zone

steven_wu added a comment. The main concern for adding this `blacklist` was because of long term maintainability since the option is going to be embedded into bitcode. Looking at this specific option, I have no reason against because it doesn't affect embedded compiler flags. I added Tim to

[PATCH] D61627: [clang driver] Allow -fembed-bitcode combined with -mno-red-zone

wanders created this revision. wanders added reviewers: steven_wu, compnerd, rsmith. wanders added a project: clang. Herald added a subscriber: dexonsmith. The -mno-red-zone (and the option to cancel it out: -mred-zone) were not allowed to be combined with -fembed-bitcode. However this option has