This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Patch RFC: disable block partitioning with split stack


> This recent patch
> https://gcc.gnu.org/ml/gcc-patches/2017-06/msg00518.html turned on
> block partitioning even when profiling is not enabled.  This can break

I am heading towards enabling block partitioning by default (because we now
have infrastructure to identify likely cold BBs), but I must admit I did
not notice I made it happen by that patch.  reorder_blocks_and_partition
is not enabled in opts.c but I see it is hidden within
common/config/i386/i386-common.c that I did not know even existed.

> code compiled with -fsplit-stack, if the cold partition calls a
> function that is not compiled with -fsplit-stack (such as a C library
> function).  The problem is that when the linker sees a split-stack
> function call a non-split-stack function, it adjusts the function
> header to request more stack space.  This doesn't work if the call is
> in the cold partition, as the linker doesn't know how to find the
> header to adjust.  You can see this by trying to build the Go library
> using the gold linker with this patch.

If code does not work, I wonder why we let user to overwrite the default
by hand? In other cases we drop the flag with inform message.

Also bb-reorder knows how to prevent landing pads to go to different sections,
so perhaps same machinery can be used to prevent splitting blocks having
calls that needs linker adjustments?

But if fixing this is involved, I am fine with how it is done in your patch.

Honza


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]