Re: AW: make static method find_reloads_address_1(...) extern accessible

[Jeff Law <law@redhat.com>]

On 9/30/19 11:25 AM, stefan@franke.ms wrote:
> 
> 
>> -----Ursprüngliche Nachricht-----
>> Von: Jeff Law <law@redhat.com>
>> Gesendet: Montag, 30. September 2019 18:23
>> An: stefan@franke.ms; gcc-help@gcc.gnu.org
>> Betreff: Re: make static method find_reloads_address_1(...) extern
>> accessible
>>
>> On 9/30/19 6:17 AM, stefan@franke.ms wrote:
>>> I've implemented LEGITIMIZE_RELOAD_ADDRESS and that implementation
>> is
>>> calling find_reloads_address_1.
>>>
>>> My implementation adds double indirect addressing to the m68k target
>>> and since the use of an outer index register or offset depends on the
>>> use of an inner index register or offset, since only one index
>>> register and one offset is allowed per address. => The recursive
>>> reload implementation does not work. So the
>> LEGITIMIZE_RELOAD_ADDRESS
>>> takes care of the whole address at once.
>>>
>>> How are the chances that a static method of reload is converted into
>>> an extern accessible method, if a patch would requires it?
>> If all you need is to make the routine visible, that may be OK.  THe biggest
>> worry is any data structures used by find_reloads_address_1 and it's children
>> and whether or not that data is valid.
> 
> It seems to work, passes the gcc.c-torture/execute tests... 
Well, that's good, but not really sufficient to determine if the patch
is correct.


> 
>> The bigger concern I have is that we're on a path to drop reload and instead
>> use LRA.  So there's a good chance that the work you do in this space doesn't
>> have a significant lifetime -- doing it in LRA would be better, at least in theory
>> -- and at least one other port would like to support double indirect
>> addressing in LRA.
>>
>> The natural question is whether or not m68k can use LRA instead of reload.
>> That's predicated on converting the m68k from cc0 to MODE_CC for
>> representing the condition codes.  Nobody is currently signed up to do this
>> work and if nobody steps up, the m68k port will end up deprecated.
> 
> There's a bounty on bountysource for this: https://www.bountysource.com/issues/80706251-m68k-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases
I'm aware.  Depending on a variety of things, my son might take a stab
at it next summer if nobody else has.  He helped on the v850 conversion
and has done some work on an h8 conversion.  The idea was to start with
easier ports, working towards the m68k.  But again, it's not a firm
commitment.

> 
> And I am confident that an adequate implementation for LRA can be done.
I'm much more concerned about the cc0 transition than LRA.  Conversion
to LRA is almost certainly a much smaller change.

> 
> Should I use the gcc development master branch (version 10 atm) or something stable for LRA?
GCC master.

Note that LRA does not support cc0 targets.  SO the cc0 transition has
to happen first.

jeff