2016-02-09 19:00 GMT+03:00 Bin.Cheng <amker.ch...@gmail.com>: > On Tue, Feb 9, 2016 at 3:53 PM, Ilya Enkovich <enkovich....@gmail.com> wrote: >> 2016-02-09 18:45 GMT+03:00 Richard Earnshaw (lists) >> <richard.earns...@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 >>>> PIC_OFFSET_TABLE_REGNUM. >>>> >>> >>> 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. Ilya > > Thanks, > bin >> >> Thanks, >> Ilya >> >>> >>> R. >>> >>>> Thanks, >>>> Ilya >>>> >>>>>
