On 23 June 2015 at 14:02, Jiong Wang <jiong.w...@arm.com> wrote: > > Marcus Shawcroft writes: > >> On 20 May 2015 at 11:21, Jiong Wang <jiong.w...@arm.com> wrote: >> >>> gcc/ >>> * config/aarch64/aarch64.md: (ldr_got_small_<mode>): Support new GOT >>> relocation >>> modifiers. >>> (ldr_got_small_sidi): Ditto. >>> * config/aarch64/iterators.md (got_modifier): New mode iterator. >>> * config/aarch64/aarch64-otps.h (aarch64_code_model): New model. >>> * config/aarch64/aarch64.c (aarch64_load_symref_appropriately): Support >>> -fpic. >>> (aarch64_rtx_costs): Add costs for new instruction sequences. >>> (initialize_aarch64_code_model): Initialize new model. >>> (aarch64_classify_symbol): Recognize new model. >>> (aarch64_asm_preferred_eh_data_format): Support new model. >>> (aarch64_load_symref_appropriately): Generate new instruction sequences >>> for -fpic. >>> (TARGET_USE_PSEUDO_PIC_REG): New definition. >>> (aarch64_use_pseudo_pic_reg): New function. >>> >>> gcc/testsuite/ >>> * gcc.target/aarch64/pic-small.c: New testcase. >> >> >> Rather than thread tests against aarch64_cmodel throughout the >> existing code can we instead extend classify_symbol with a new symbol >> classification? > > Yes, we can. As -fPIC/-fpic allow 4G/32K GOT table size, we may name > corresponding symbol classification as "SYMBOL_GOT_4G", > "SYMBOL_GOT_32K". > > But can we let this patch go in and create a another patch to improve > this? there are several other TLS patches may needs rebase if we change > this immedaitely.
We can wait for a proper solution that fits with the code already in place.
