make static method find_reloads_address_1(...) extern accessible

make static method find_reloads_address_1(...) extern accessible

[stefan]

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?

Regards

Stefan

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

[Jonathan Wakely]

On Mon, 30 Sep 2019 at 13:17, <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 you're talking about modifying GCC then you should probably use the
gcc@ mailing list, not this one.

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

[Jeff Law]

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.

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.


Jeff

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

[stefan]

> -----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... 

> 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

And I am confident that an adequate implementation for LRA can be done.

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


Stefan

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

[Jeff Law]

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