diff options
| author | Andreas Krebbel <krebbel@linux.ibm.com> | 2023-06-26 18:31:53 +0200 |
|---|---|---|
| committer | Andreas Krebbel <krebbel@linux.ibm.com> | 2023-06-26 18:41:16 +0200 |
| commit | a29df49b7d8332f068926a45c950510ceeb79f4c (patch) | |
| tree | 90445ecc4b6099157b064a3e73d911b7facbe836 /libjava/javax/management/Query$OrQueryExp.h | |
| parent | c2ebccc97190a978a44e341516b488f02a78c598 (diff) | |
| download | gcc-a29df49b7d8332f068926a45c950510ceeb79f4c.zip gcc-a29df49b7d8332f068926a45c950510ceeb79f4c.tar.gz gcc-a29df49b7d8332f068926a45c950510ceeb79f4c.tar.bz2 | |
IBM zSystems: Assume symbols without explicit alignment to be ok
A change we have committed back in 2015 relies on the backend
requested ABI alignment to be applied to ALL symbols by the
middle-end. However, this does not appear to be the case for external
symbols. With this commit we assume all symbols without explicit
alignment to be aligned according to the ABI. That's the behavior we
had before.
This fixes a performance regression caused by the 2015 patch. Since
then the address of external char type symbols have been pushed to the
literal pool, although it is safe to access them with larl (which
requires symbols to reside at even addresses).
gcc/
* config/s390/s390.cc (s390_encode_section_info): Set
SYMBOL_FLAG_SET_NOTALIGN2 only if the symbol has explicitely been
misaligned.
gcc/testsuite/
* gcc.target/s390/larl-1.c: New test.
Diffstat (limited to 'libjava/javax/management/Query$OrQueryExp.h')
0 files changed, 0 insertions, 0 deletions