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

Tue May 7 11:19:39 PDT 2019

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 some memory outside of current stack pointer, so that a program can use that stack memory without adjusting the stackpointer. When compiling with `-mno-red-zone` the program will not use that but instead always adjust the stack pointer.  So compiling an application with `-mno-red-zone` on a platform which allows red-zone usage will just cause some extra stack pointer adjustments, but not real ABI problems?    On the other hand, compiling with `-mred-zone` (default) on a system that does not allow red-zone will risk strange corruptions when program has put data on stack without adjusting stackpointer and a signal/interrupt arrives.

If my reasoning there happens to be correct I think that `-mno-red-zone` should be safe to lift of the blacklist, but `-mred-zone` should be kept on the black list (at least if there is/can be such a thing as a platform where `-mno-red-zone` is the default)

I think this is similar to `-mno-implicit-float` which _is_ allowed to combined with `-fembed-bitcode`. One could easily envision a platform where fpu registers are not preserved on signal/interrupts. And then `-mimplicit-float` would be broken. However using `-mno-implicit-float` on a platform where the they are preserved is fine (except for possible performance loss).

I'm also a bit unsure about exact reasons for putting things in the blacklist. I'd also like to remove `-mcmodel=` from the blacklist. So maybe I should start a separate thread on cfe-dev on this for a more general discussion.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D61627/new/

https://reviews.llvm.org/D61627