Laurent Desnogues wrote:
> On Sun, Mar 8, 2009 at 4:36 PM, Jan Kiszka <jan.kiszka@web.de> wrote:
>> Laurent Desnogues wrote:
>>> On Sun, Mar 8, 2009 at 3:41 PM, Jan Kiszka <jan.kiszka@web.de> wrote:
>>>> Also, some discussion on this list suggested that it's more efficient to
>>>> look into converting the remaining AREGS to TCG and finally do the
>>>> ultimative "rm dyngen-exec.h". Don't you want to spend some time on this
>>>> already?
>>> This requires modifying ARM translator which is the last one to use
>>> AREGn with n>0. And don't all targets use AREG0 as a pointer to the
>>> CPU state?
>> Yes, but wasn't it you who suggested that all those users should be
>> converted over to the tcg_global_reg API?
> 
> Yes, and I did the work for ARM.  However when considering the
> removal of AREG0, and after looking at generated code, I came
> to the perhaps premature conclusion that removing it would not
> bring me any speedup (at least for a not so register starved
> target as x86_64).

I don't think we are looking for speedup here, just for cleanup. Status
quo regarding performance after a conversion would be more than fine IMHO.

> 
>> There is surely some work to do, and that probably across all archs. But
>> the sooner we should start. dyngen-exec.h is a constant source of pain
>> when you try to introduce new headers or refactor existing ones.
> 
> Well dyngen-exec.h is long gone in my sources even though
> AREG0 is still used.  I would have to backtrack my changes to
> see how I arrived to that, but for sure the first thing to do is to
> remove cpu_T from ARM target.

Yes, please share your wisdom!

Jan