2014-08-25 15:24 GMT+04:00 Hans-Peter Nilsson <h...@bitrange.com>:
> On Mon, 25 Aug 2014, Ilya Enkovich wrote:
>> 2014-08-23 5:47 GMT+04:00 Hans-Peter Nilsson <h...@bitrange.com>:
>> > ...did you send the right version of the patch?
>> > This one uses the RTX-returning hook only in boolean tests,
>> > unless I misread.
>
> (I did, but not by much.)
>
>> NULL returned by hook means we do not have implicit pic arg to
>> pass/receive and there are pieces of code which should be executed
>> only when implicit pic arg exists. This causes these boolean tests.
>
> Well, obviously, but...
>
>> There are also non boolean usages. E.g.:
>
> I thing singular ("usage") is more correct?
> I saw only one such use. :)
There is another one in i386.c :)
>
>> + rtx old_reg = targetm.calls.implicit_pic_arg (fndecl);
>> + rtx new_reg = gen_reg_rtx (GET_MODE (old_reg));
>> + emit_move_insn (new_reg, old_reg);
>> + pic_offset_table_rtx = new_reg;
>
> And before that, it's called as a boolean test, throwing away
> the result!
>
> I suggest you change the hook to return a boolean, with a
> pointer argument to a variable to set, passed as NULL from
> callers not interested in the actual value.
>
> I.e. instead of:
>
>> >> +@deftypefn {Target Hook} rtx TARGET_IMPLICIT_PIC_ARG (const_tree
>> >> @var{fntype_or_decl})
>
> make it a:
>
> @deftypefn {Target Hook} bool TARGET_IMPLICIT_PIC_ARG
> (const_tree @var{fntype_or_decl}, rtx *@var{addr})
OK. I'll change this hook if it goes to a product quality patch.
Current patch is posted to demonstrate an approach and show narrow
points I have to deal with in reload. There is no reason in cleaning
it until a decision about next steps is made.
Thanks,
Ilya
>
> brgds, H-P
