This is the mail archive of the
mailing list for the GCC project.
Re: Inconsistent initialization for pic_offset_table_rtx?
- From: Ilya Enkovich <enkovich dot gnu at gmail dot com>
- To: "Bin.Cheng" <amker dot cheng at gmail dot com>
- Cc: "Richard Earnshaw (lists)" <Richard dot Earnshaw at arm dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Tue, 9 Feb 2016 19:08:07 +0300
- Subject: Re: Inconsistent initialization for pic_offset_table_rtx?
- Authentication-results: sourceware.org; auth=none
- References: <CAHFci28XosGqkHXjA1_=XU3f6M2anq4NTwCntY5adV+JKeD-Zw at mail dot gmail dot com> <CAMbmDYbN7DJJuXPhQ-8TpYh2Yj9bFcP1MyncNr9iaS9LX9L1+Q at mail dot gmail dot com> <CAHFci2-Qb1NadLD+CUEOSBcbqrc74cMaQV_=fatw9AB47dFakQ at mail dot gmail dot com> <CAMbmDYaeO1RCjZUV5EMC3Q2ip1r=Sggymd=8qqwRPpUGYvEB4w at mail dot gmail dot com> <CAHFci2992=9Y8qNiKskbyaS770zJng7tDoqDaGnCg69w=fXePw at mail dot gmail dot com> <CAMbmDYYX3UUCHsaOLyTyjRb=nt0Y6axF4XZedLVBPG2DBo7KAA at mail dot gmail dot com> <56BA09AF dot 1080907 at arm dot com> <CAMbmDYaorVj-xcxz0iy3+-W3YOtwnbVLef6B07bXBhWW2P8b+A at mail dot gmail dot com> <CAHFci2_psjn=R22iUn4UrpNQ7xB5ov2TWQYBCzNuB8UJm-=AYQ at mail dot gmail dot com>
2016-02-09 19:00 GMT+03:00 Bin.Cheng <email@example.com>:
> On Tue, Feb 9, 2016 at 3:53 PM, Ilya Enkovich <firstname.lastname@example.org> wrote:
>> 2016-02-09 18:45 GMT+03:00 Richard Earnshaw (lists) <Richard.Earnshaw@arm.com>:
>>> On 09/02/16 14:56, Ilya Enkovich wrote:
>>>> I agree it looks inconsistent. But I don't think PIC_OFFSET_TABLE_REGNUM is
>>>> supposed to return pseudo regno. Using EBX_REG value for this macro was a
>>>> workaround for problem of NULL pic_offset_table_rtx usage in cost
>>>> functions. I think
>>>> we should try to initialize pic_offset_table_rtx with some pseudo
>>>> register in i386
>>>> target for cost estimation purposes and always return INVALID_REG for
>>> The ARM port has been using a pseudo for P_O_T_R for many years now. It
>>> needs some care to establish it correctly in the prologue when needed,
>>> but otherwise works very well. It means that leaf functions in
>>> particular can be made much more efficient as they can pick a
>>> call-clobbered register when that's desirable.
>> We may need it from middle-end when estimate statements cost. So
>> initialization in
>> prologue is not enough (at least for i386 target). Looks like those
>> cost estimation hooks
>> should take care of PIC register by themselves.
> By cost estimation hooks, do you mean xxx_address_cost here? Middle
> end itself doesn't know how PIC register is supported by targets. I
> admit that there is a missing part for PIC register in register
> pressure estimate in IVO.
> IIUC, the hardreg is only used for cost estimation in middle end here,
> and it's only used for the first function in each compilation unit,
> right? It's overridden into pseudo register when expanding the first
> function anyway?
I understand it in the same way. I'm not sure if any of IPA or local
optimization passes are affected. Those are executed before any
function expansion and therefore will have EBX as PIC register if use
corresponding target hooks.