Ilya Leoshkevich wrote:
> TARGET_CPU_ZARCH allowed to distinguish between g5/g6 and newer
> machines. Since the former are now gone, we can assume that
> TARGET_CPU_ZARCH is always true. As a side-effect, branch splitting
> is now completely gone. Some parts of literal pool splitting are
> also gone, but it's still there: we need to support it because
> floating point and vector instructions still cannot use relative
> addressing.
Great to see this finally go!
B.t.w. the literal pool handling can be simplified further now.
The current code was made complicated due to the potential of
interaction between branch splitting and literal pool splitting,
see the long comment:
However, the two problems are interdependent: splitting the
literal pool can move a branch further away from its target,
causing the 64K limit to overflow, and on the other hand,
replacing a PC-relative branch by an absolute branch means
we need to put the branch target address into the literal
pool, possibly causing it to overflow.
So, we loop trying to fix up both problems until we manage
to satisfy both conditions at the same time. [...]
Since branch splitting is gone, this whole logic is superfluous;
the loop will never execute more than once. (It may not be
necessary any longer to split the logic into the various
chunkify_start/finish routines either ...)
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
