qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* RE: [PATCH 1/4] target/ppc: Code motion required to build disabling tcg
@ 2021-04-12 12:05 Bruno Piazera Larsen
  2021-04-12 13:56 ` Fabiano Rosas
  2021-04-13  6:40 ` David Gibson
  0 siblings, 2 replies; 24+ messages in thread
From: Bruno Piazera Larsen @ 2021-04-12 12:05 UTC (permalink / raw)
  To: David Gibson, Fabiano Rosas, Thomas Huth
  Cc: Luis Fernando Fujita Pires, qemu-devel, lagarcia,
	Lucas Mateus Martins Araujo e Castro, Fernando Eckhardt Valle,
	qemu-ppc, Andre Fernando da Silva, Matheus Kowalczuk Ferst

[-- Attachment #1: Type: text/plain, Size: 4657 bytes --]

> A general advice for this whole series is: make sure you add in some
> words explaining why you decided to make a particular change. It will be
> much easier to review if we know what were the logical steps leading to
> the change.

Fair point, I should've thought about that.

> > This commit does the necessary code motion from translate_init.c.inc
>
> For instance, I don't immediately see why these changes are necessary. I
> see that translate_init.c.inc already has some `#ifdef CONFIG_TCG`, so
> why do we need to move a bunch of code into cpu.c instead of just adding
> more code under ifdef CONFIG_TCG? (I'm not saying it's wrong, just trying to
> understand the reasoning).

There are 3 main reasons for this decision. The first is kind of silly, but when I read translate.c my mind jumped to translating machine code to TCG, and the amount of TCGv variables at the start reinforced this notion.
The second was that both s390x and i386 removed it (translate.c) from compilation, so I had no good reason to doubt it.
The last (and arguably most important) is that translate.c is many thousands of lines long (translate_init.c.inc alone was almost 11k). The whole point of disabling TCG is to speed up compilation and reduce the final file size, so I think it makes sense to remove that big file.
And the final nail in the coffin is that at no point did it cross my mind to keep the init part of translation, but remove the rest

Also, I'm not a fan of big ifdefs, because it's kinda hard to follow them when viewing code in vim. Adding that to already having a cpu.c file, where it makes sense (to me, at least) to add all CPU related functions, just sounded like a good idea.

> Is translate_init.c.inc intended to be TCG only? But then I see you
> moved TCG-only functions out of it (ppc_fixup_cpu) and left not TCG-only
> functions (gen_spr_generic).

This is me misjudging what is TCG and what is not, mostly. I think that actually moving everything to cpu.c and adding ifdefs, or creating a cpu_tcg.c.inc or similar, would be the most sensible code motion, but every function I removed from translate gave me 3 new errors, at some point I felt like I should leave something behind otherwise we're compiling everything from TCG again, just in different files, so I tried to guess what was TCG and what was not (also, I really wanted the RFC out by the weekend, I _may_ have rushed a few choices).

> > This moves all functions that start with gdb_* into target/ppc/gdbstub.c
> > and creates a new function that calls those and is called by ppc_cpu_realize
>
> This looks like it makes sense regardless of disable-tcg, could we have
> it in a standalone patch?

Sure, I'll try and get it ready ASAP, and make sure I didn't miss one function before sending. Just a noob question... do I edit the patch manually to have it only contain the gdb code motion, or is there a way to move back to before I actually made the commit without needing to re-do the changes?

Thomas, I'm adding you to this discussion since it sort of answers your message on the other one, about the functions used even in a KVM-only build.

> IIRC you don't only have to exclude translate.c from the build, you also
> have to separate translate_init.c.inc from it, i.e. turn
> translate_init.c.inc into a proper .c file and get rid of the #include
> "translate_init.c.inc" statement in translate.c, since many functions in the
> translate_init.c.inc file are still needed for the KVM-only builds, too. So
> maybe that's a good place to start as a first mini series.

Now that I know that translate doesn't mean "translating to TCG", this idea makes more sense. My question is, is it a better option than the code motion I'm suggesting? From my quick check on the bits that I haven't touched it might, but at this point it's clear I'm very lost with what makes sense hahaha.


Bruno Piazera Larsen

Instituto de Pesquisas ELDORADO<http://clickemailmkt.eldorado.org.br/ls/click?upn=UPoxpeIcHnAcbUZyo7TTaswyiVb1TXP3jEbQqiiJKKGsxOn8hBEs5ZsMLQfXkKuKXZ7MVDg0ij9eG8HV4TXI75dBzDiNGLxQ8Xx5PzCVNt6TpGrzBbU-2Biu0o69X5ce-2FW-2FOk1uUipuK0fZnWXJEgbRw-3D-3DJY4T_wWk-2BG6VvNBoa1YzxYjhCdFS9IfANIaBzDSklR1NyyrKOI1wj0P-2BdBFcuO4FnHcsA1MyHu0ly1Yt3oDMp7KKdJPM68iKuI2jiRH5v4B0d8wf3chU3qy5n5iXWnW1QjSaNFHOgELzxaP-2FnesTeBgJ5dFkjH4f279sVQpOtyjw5xAqj34M6pgNRAxVvuXif4IWDcVzXg1FzfYlEfkKzr9vvpA3Hg8kitwMtlU3zwbQUBCgL30fQoJPcRPMGKyOY8RmoAlXNqTJYDYIvqmfnI7KLUvw6vKB5R-2B5q1FJRAzX7H-2BmF0NnDET6jMLuIqtCcVIch>

Departamento Computação Embarcada

Analista de Software Trainee

Aviso Legal - Disclaimer<https://www.eldorado.org.br/disclaimer.html>

[-- Attachment #2: Type: text/html, Size: 10238 bytes --]

^ permalink raw reply	[flat|nested] 24+ messages in thread
* RE: [PATCH 1/4] target/ppc: Code motion required to build disabling tcg
@ 2021-04-22 12:34 Bruno Piazera Larsen
  2021-04-22 19:35 ` Fabiano Rosas
  0 siblings, 1 reply; 24+ messages in thread
From: Bruno Piazera Larsen @ 2021-04-22 12:34 UTC (permalink / raw)
  To: David Gibson
  Cc: Thomas Huth, Fabiano Rosas, qemu-devel, Andre Fernando da Silva,
	Lucas Mateus Martins Araujo e Castro, Fernando Eckhardt Valle,
	qemu-ppc, lagarcia, Matheus Kowalczuk Ferst,
	Luis Fernando Fujita Pires

[-- Attachment #1: Type: text/plain, Size: 6565 bytes --]

> > You are correct! I've just tweaked the code that defines spr_register and
> > it should be working now. I'm still working in splitting the SPR functions
> > from translate_init, since I think it would make it easier to prepare the
> > !TCG case and for adding new architectures in the future, and I found a
> > few more problems:
>
> Actually looking at the stuff below, I suspect that separating our
> "spr" logic specifically might be a bad idea.  At least some of the
> SPRs control pretty fundamental things about how the processor
> operates, and I suspect separating it from the main translation logic
> may be more trouble than it's worth.

Well, all the errors that I got were related to to read/write functions, which
I was already separating into a spr_tcg file. The solutions I can see are to
include this file in translate.c, and either have the read/write functions not be
static, or include the spr_common.c in translate as well, but only for TCG
builds. Both solutions sound pretty bad imo, but the first sounds less bad,
because it's a bit less complexity in the build process.

Other than that, I don't really see how we can support a !TCG build without
separating SPR, exactly because they are very fundamental to the processor.
Am I missing something? I fully expect to be, at this point, things are
turning out even more complicated than I expected



Bruno Piazera Larsen

Instituto de Pesquisas ELDORADO<http://clickemailmkt.eldorado.org.br/ls/click?upn=UPoxpeIcHnAcbUZyo7TTaswyiVb1TXP3jEbQqiiJKKGsxOn8hBEs5ZsMLQfXkKuKXZ7MVDg0ij9eG8HV4TXI75dBzDiNGLxQ8Xx5PzCVNt6TpGrzBbU-2Biu0o69X5ce-2FW-2FOk1uUipuK0fZnWXJEgbRw-3D-3DJY4T_wWk-2BG6VvNBoa1YzxYjhCdFS9IfANIaBzDSklR1NyyrKOI1wj0P-2BdBFcuO4FnHcsA1MyHu0ly1Yt3oDMp7KKdJPM68iKuI2jiRH5v4B0d8wf3chU3qy5n5iXWnW1QjSaNFHOgELzxaP-2FnesTeBgJ5dFkjH4f279sVQpOtyjw5xAqj34M6pgNRAxVvuXif4IWDcVzXg1FzfYlEfkKzr9vvpA3Hg8kitwMtlU3zwbQUBCgL30fQoJPcRPMGKyOY8RmoAlXNqTJYDYIvqmfnI7KLUvw6vKB5R-2B5q1FJRAzX7H-2BmF0NnDET6jMLuIqtCcVIch>

Departamento Computação Embarcada

Analista de Software Trainee

Aviso Legal - Disclaimer<https://www.eldorado.org.br/disclaimer.html>

________________________________
De: David Gibson
Enviadas: Quarta-feira, 21 de Abril de 2021 02:13
Para: Bruno Piazera Larsen
Cc: Fabiano Rosas; Thomas Huth; qemu-devel@nongnu.org; lagarcia@br.ibm.com; Lucas Mateus Martins Araujo e Castro; Fernando Eckhardt Valle; qemu-ppc@nongnu.org; Andre Fernando da Silva; Matheus Kowalczuk Ferst; Luis Fernando Fujita Pires
Assunto: Re: [PATCH 1/4] target/ppc: Code motion required to build disabling tcg

On Tue, Apr 20, 2021 at 07:02:36PM +0000, Bruno Piazera Larsen wrote:
> > > What I was doing was to only register the spr once, and use the
> > > accel-specific functions to set the relevant attributes, so spr_common
> > > wouldn't need to where (and if) spr_read_* exists or not.
> > > Would this work?
> > >
> > > Just ignoring the read and write functions means we still need
> > > to compile them, or at least stub them, otherwise we'd get linker
> > > problems.
> >
> > Not if you use a macro which will simply elide the references in the
> > !TCG case.  Actually I think even an inline wrapper will do it, I'm
> > pretty sure the compiler is smart enough to optimize the references
> > out in that case.
>
> You are correct! I've just tweaked the code that defines spr_register and
> it should be working now. I'm still working in splitting the SPR functions
> from translate_init, since I think it would make it easier to prepare the
> !TCG case and for adding new architectures in the future, and I found a
> few more problems:

Actually looking at the stuff below, I suspect that separating our
"spr" logic specifically might be a bad idea.  At least some of the
SPRs control pretty fundamental things about how the processor
operates, and I suspect separating it from the main translation logic
may be more trouble than it's worth.

> 1. Global variables being defined in translate.c and used both there and
> in spr functions. The variables in question are: cpu_gpr, cpu_so, cpu_ov,
> cpu_ca, cpu_ov32, cpu_ca32, cpu_xer, cpu_lr and cpu_ctr. The easy way
> out is to have global "getters" and "setters" for those, but I'm not sure
> it's a good solution.

Yeah, that seems really messy, plus those are special variables used
by TCG generated code whose operation I don't really understand.

> 2. Static functions defined in translate.c, used there and TCG-related
> spr functions. They are: gen_load_spr, gen_store_spr, gen_stop_exception,
> gen_inval_exception. The easy solution is adding a prototype to internal.h
> and removing the static, but again, not sure it's a good solution

I think gen_*() functions should stay in translate.c, since they are,
explicitly, about translation ("gen" for "generating code").

> 3. gen_read_xer (currently in spr_common) calls is_isa300, defined in
> include/disas/disas.h, which is a macro that dereferences DisasContext.
> However, the struct is defined in translate.c. This one is pretty easy, I think,
> it's just turning the macro into a function, but since I'm already e-mailing,
> I figured I might as weel ask.
>
> Finally, since most read and write functions are static, I added them to
> spr_tcg.c.inc to be included only with TCG, as a quick fix, but I would really
> prefer some other solution if there is anything better. Any thoughts on this?
>
> IIRC, this is the last thing holding me back from an RFC with this motion
> patch
>
>
> Bruno Piazera Larsen
>
> Instituto de Pesquisas ELDORADO<http://clickemailmkt.eldorado.org.br/ls/click?upn=UPoxpeIcHnAcbUZyo7TTaswyiVb1TXP3jEbQqiiJKKGsxOn8hBEs5ZsMLQfXkKuKXZ7MVDg0ij9eG8HV4TXI75dBzDiNGLxQ8Xx5PzCVNt6TpGrzBbU-2Biu0o69X5ce-2FW-2FOk1uUipuK0fZnWXJEgbRw-3D-3DJY4T_wWk-2BG6VvNBoa1YzxYjhCdFS9IfANIaBzDSklR1NyyrKOI1wj0P-2BdBFcuO4FnHcsA1MyHu0ly1Yt3oDMp7KKdJPM68iKuI2jiRH5v4B0d8wf3chU3qy5n5iXWnW1QjSaNFHOgELzxaP-2FnesTeBgJ5dFkjH4f279sVQpOtyjw5xAqj34M6pgNRAxVvuXif4IWDcVzXg1FzfYlEfkKzr9vvpA3Hg8kitwMtlU3zwbQUBCgL30fQoJPcRPMGKyOY8RmoAlXNqTJYDYIvqmfnI7KLUvw6vKB5R-2B5q1FJRAzX7H-2BmF0NnDET6jMLuIqtCcVIch>
>
> Departamento Computação Embarcada
>
> Analista de Software Trainee
>
> Aviso Legal - Disclaimer<https://www.eldorado.org.br/disclaimer.html>

--
David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: Type: text/html, Size: 12042 bytes --]

^ permalink raw reply	[flat|nested] 24+ messages in thread
* RE: [PATCH 1/4] target/ppc: Code motion required to build disabling tcg
@ 2021-04-20 19:02 Bruno Piazera Larsen
  2021-04-21  5:13 ` David Gibson
  0 siblings, 1 reply; 24+ messages in thread
From: Bruno Piazera Larsen @ 2021-04-20 19:02 UTC (permalink / raw)
  To: David Gibson
  Cc: Thomas Huth, Fabiano Rosas, qemu-devel, Andre Fernando da Silva,
	Lucas Mateus Martins Araujo e Castro, Fernando Eckhardt Valle,
	qemu-ppc, lagarcia, Matheus Kowalczuk Ferst,
	Luis Fernando Fujita Pires

[-- Attachment #1: Type: text/plain, Size: 2970 bytes --]

> > What I was doing was to only register the spr once, and use the
> > accel-specific functions to set the relevant attributes, so spr_common
> > wouldn't need to where (and if) spr_read_* exists or not.
> > Would this work?
> >
> > Just ignoring the read and write functions means we still need
> > to compile them, or at least stub them, otherwise we'd get linker
> > problems.
>
> Not if you use a macro which will simply elide the references in the
> !TCG case.  Actually I think even an inline wrapper will do it, I'm
> pretty sure the compiler is smart enough to optimize the references
> out in that case.

You are correct! I've just tweaked the code that defines spr_register and
it should be working now. I'm still working in splitting the SPR functions
from translate_init, since I think it would make it easier to prepare the
!TCG case and for adding new architectures in the future, and I found a
few more problems:

1. Global variables being defined in translate.c and used both there and
in spr functions. The variables in question are: cpu_gpr, cpu_so, cpu_ov,
cpu_ca, cpu_ov32, cpu_ca32, cpu_xer, cpu_lr and cpu_ctr. The easy way
out is to have global "getters" and "setters" for those, but I'm not sure
it's a good solution.

2. Static functions defined in translate.c, used there and TCG-related
spr functions. They are: gen_load_spr, gen_store_spr, gen_stop_exception,
gen_inval_exception. The easy solution is adding a prototype to internal.h
and removing the static, but again, not sure it's a good solution

3. gen_read_xer (currently in spr_common) calls is_isa300, defined in
include/disas/disas.h, which is a macro that dereferences DisasContext.
However, the struct is defined in translate.c. This one is pretty easy, I think,
it's just turning the macro into a function, but since I'm already e-mailing,
I figured I might as weel ask.

Finally, since most read and write functions are static, I added them to
spr_tcg.c.inc to be included only with TCG, as a quick fix, but I would really
prefer some other solution if there is anything better. Any thoughts on this?

IIRC, this is the last thing holding me back from an RFC with this motion
patch


Bruno Piazera Larsen

Instituto de Pesquisas ELDORADO<http://clickemailmkt.eldorado.org.br/ls/click?upn=UPoxpeIcHnAcbUZyo7TTaswyiVb1TXP3jEbQqiiJKKGsxOn8hBEs5ZsMLQfXkKuKXZ7MVDg0ij9eG8HV4TXI75dBzDiNGLxQ8Xx5PzCVNt6TpGrzBbU-2Biu0o69X5ce-2FW-2FOk1uUipuK0fZnWXJEgbRw-3D-3DJY4T_wWk-2BG6VvNBoa1YzxYjhCdFS9IfANIaBzDSklR1NyyrKOI1wj0P-2BdBFcuO4FnHcsA1MyHu0ly1Yt3oDMp7KKdJPM68iKuI2jiRH5v4B0d8wf3chU3qy5n5iXWnW1QjSaNFHOgELzxaP-2FnesTeBgJ5dFkjH4f279sVQpOtyjw5xAqj34M6pgNRAxVvuXif4IWDcVzXg1FzfYlEfkKzr9vvpA3Hg8kitwMtlU3zwbQUBCgL30fQoJPcRPMGKyOY8RmoAlXNqTJYDYIvqmfnI7KLUvw6vKB5R-2B5q1FJRAzX7H-2BmF0NnDET6jMLuIqtCcVIch>

Departamento Computação Embarcada

Analista de Software Trainee

Aviso Legal - Disclaimer<https://www.eldorado.org.br/disclaimer.html>

[-- Attachment #2: Type: text/html, Size: 6820 bytes --]

^ permalink raw reply	[flat|nested] 24+ messages in thread
* RE: [PATCH 1/4] target/ppc: Code motion required to build disabling tcg
@ 2021-04-19 14:40 Bruno Piazera Larsen
  2021-04-20  1:20 ` David Gibson
  0 siblings, 1 reply; 24+ messages in thread
From: Bruno Piazera Larsen @ 2021-04-19 14:40 UTC (permalink / raw)
  To: David Gibson, Fabiano Rosas
  Cc: Thomas Huth, qemu-devel, Andre Fernando da Silva,
	Lucas Mateus Martins Araujo e Castro, Fernando Eckhardt Valle,
	qemu-ppc, lagarcia, Matheus Kowalczuk Ferst,
	Luis Fernando Fujita Pires

[-- Attachment #1: Type: text/plain, Size: 2677 bytes --]

> > > * move gen_write_xer and gen_read_xer into cpu_init.c, as they're
> > > used for some sprs, and whatever needs to be moved with it
> >
> > I'd leave them where they are currently. Instead what I think we should
> > do is to find a way to not need the uea/oea/hea|read/write callbacks
> > with KVM.
> >
> > Maybe extract a function from _spr_register that sets what is common for
> > both tcg and kvm (num, name, initial_value, AFAICT). Then alter the
> > gen_spr* functions to first create all registers and then call both
> > configs to supplement:
> >
> > //tcg.c
> > static void tcg_gen_spr_generic(CPUPPCState *env)
> > {
> >     // these only set the callbacks
> >     spr_register(env, SPR_FOO,
> >                  SPR_NOACCESS, SPR_NOACCESS,
> >                  &spr_read_foo, &spr_write_foo);
> >     spr_register(env, SPR_BAR,
> >                  SPR_NOACCESS, SPR_NOACCESS,
> >                  &spr_read_bar, &spr_write_bar);
> > }
> >
> > //kvm.c
> > static void kvm_gen_spr_generic(CPUPPCState *env)
> > {
> >     // these only set one_reg_id
> >     spr_register_kvm(env, SPR_FOO, KVM_REG_PPC_FOO);
> >     spr_register_kvm(env, SPR_BAR, KVM_REG_PPC_BAR);
> > }
>
> I really dislike the idea above - it'd be way too easy for KVM and TCG
> to get out of sync.  Instead make spr_register() itself a macro if
> necessary, so it just ignores the access functions in the !TCG case.

What I was doing was to only register the spr once, and use the
accel-specific functions to set the relevant attributes, so spr_common
wouldn't need to where (and if) spr_read_* exists or not.
Would this work?

Just ignoring the read and write functions means we still need
to compile them, or at least stub them, otherwise we'd get linker
problems. And ifdef'ing them out of the calls would be quite a
pain to understand the code later on.



Bruno Piazera Larsen

Instituto de Pesquisas ELDORADO<http://clickemailmkt.eldorado.org.br/ls/click?upn=UPoxpeIcHnAcbUZyo7TTaswyiVb1TXP3jEbQqiiJKKGsxOn8hBEs5ZsMLQfXkKuKXZ7MVDg0ij9eG8HV4TXI75dBzDiNGLxQ8Xx5PzCVNt6TpGrzBbU-2Biu0o69X5ce-2FW-2FOk1uUipuK0fZnWXJEgbRw-3D-3DJY4T_wWk-2BG6VvNBoa1YzxYjhCdFS9IfANIaBzDSklR1NyyrKOI1wj0P-2BdBFcuO4FnHcsA1MyHu0ly1Yt3oDMp7KKdJPM68iKuI2jiRH5v4B0d8wf3chU3qy5n5iXWnW1QjSaNFHOgELzxaP-2FnesTeBgJ5dFkjH4f279sVQpOtyjw5xAqj34M6pgNRAxVvuXif4IWDcVzXg1FzfYlEfkKzr9vvpA3Hg8kitwMtlU3zwbQUBCgL30fQoJPcRPMGKyOY8RmoAlXNqTJYDYIvqmfnI7KLUvw6vKB5R-2B5q1FJRAzX7H-2BmF0NnDET6jMLuIqtCcVIch>

Departamento Computação Embarcada

Analista de Software Trainee

Aviso Legal - Disclaimer<https://www.eldorado.org.br/disclaimer.html>

________________________________

[-- Attachment #2: Type: text/html, Size: 7276 bytes --]

^ permalink raw reply	[flat|nested] 24+ messages in thread
* RE: [PATCH 1/4] target/ppc: Code motion required to build disabling tcg
@ 2021-04-13 17:43 Bruno Piazera Larsen
  2021-04-13 21:38 ` Fabiano Rosas
                   ` (2 more replies)
  0 siblings, 3 replies; 24+ messages in thread
From: Bruno Piazera Larsen @ 2021-04-13 17:43 UTC (permalink / raw)
  To: David Gibson
  Cc: Thomas Huth, Fabiano Rosas, qemu-devel, lagarcia,
	Lucas Mateus Martins Araujo e Castro, Fernando Eckhardt Valle,
	qemu-ppc, Andre Fernando da Silva, Matheus Kowalczuk Ferst,
	Luis Fernando Fujita Pires

[-- Attachment #1: Type: text/plain, Size: 8297 bytes --]

> I'm actually not sure if we'll want translate_init.c for !tcg builds.
> It's *primarily* for TCG, but we still need at least some of the cpu
> state structure for KVM, and some of that is initialized in
> translate_init.
>
> I think it will probably make more sense to leave it in for a first
> cut.  Later refinement might end up removing it.
>
> The whole #include translate_init.c.inc thing might make for some
> awkward fiddling in this, of course.

I just checked, there is going to be some shuffling of functions
around, as there are some static variables defined on translate.c,
and used in translate_init.c.inc, some functions needed for KVM
on translate.c and some TCG only functions in the
translate_init.c.inc.

The trivial path is to:
* rename translate_init.c.inc to cpu_init.c (since it has to do with
initial definitions for CPUs, and it's not related to translating
anymore);
* move gen_write_xer and gen_read_xer into cpu_init.c, as they're
used for some sprs, and whatever needs to be moved with it
* move is_indirect_opcode and ind_table to translate.c, since they
are used to translate ppc instructions, and the things defined for
these functions
* Figure out what needs to be added to the includes for both
files to compile
* move opcodes and invalid_handler into cpu_init.c, because they
are only used by stuff in this file.

I'm just not sure about this last point. The stuff that use opcodes
create the callback tables for TCG, AFAICT. The better plan would
be to move all of that to tanslate.c, but might be a lot.

Can I follow the trivial plan for the first cut and leave a TODO in
the code for a better solution in the future? Or is there a nuance
about one of those functions that I have not understood?


Bruno Piazera Larsen

Instituto de Pesquisas ELDORADO<http://clickemailmkt.eldorado.org.br/ls/click?upn=UPoxpeIcHnAcbUZyo7TTaswyiVb1TXP3jEbQqiiJKKGsxOn8hBEs5ZsMLQfXkKuKXZ7MVDg0ij9eG8HV4TXI75dBzDiNGLxQ8Xx5PzCVNt6TpGrzBbU-2Biu0o69X5ce-2FW-2FOk1uUipuK0fZnWXJEgbRw-3D-3DJY4T_wWk-2BG6VvNBoa1YzxYjhCdFS9IfANIaBzDSklR1NyyrKOI1wj0P-2BdBFcuO4FnHcsA1MyHu0ly1Yt3oDMp7KKdJPM68iKuI2jiRH5v4B0d8wf3chU3qy5n5iXWnW1QjSaNFHOgELzxaP-2FnesTeBgJ5dFkjH4f279sVQpOtyjw5xAqj34M6pgNRAxVvuXif4IWDcVzXg1FzfYlEfkKzr9vvpA3Hg8kitwMtlU3zwbQUBCgL30fQoJPcRPMGKyOY8RmoAlXNqTJYDYIvqmfnI7KLUvw6vKB5R-2B5q1FJRAzX7H-2BmF0NnDET6jMLuIqtCcVIch>

Departamento Computação Embarcada

Analista de Software Trainee

Aviso Legal - Disclaimer<https://www.eldorado.org.br/disclaimer.html>

________________________________
De: David Gibson
Enviadas: Terça-feira, 13 de Abril de 2021 03:40
Para: Bruno Piazera Larsen
Cc: Fabiano Rosas; Thomas Huth; qemu-devel@nongnu.org; Luis Fernando Fujita Pires; Andre Fernando da Silva; Lucas Mateus Martins Araujo e Castro; Fernando Eckhardt Valle; qemu-ppc@nongnu.org; lagarcia@br.ibm.com; Matheus Kowalczuk Ferst
Assunto: Re: [PATCH 1/4] target/ppc: Code motion required to build disabling tcg

On Mon, Apr 12, 2021 at 12:05:31PM +0000, Bruno Piazera Larsen wrote:
> > A general advice for this whole series is: make sure you add in some
> > words explaining why you decided to make a particular change. It will be
> > much easier to review if we know what were the logical steps leading to
> > the change.
>
> Fair point, I should've thought about that.
>
> > > This commit does the necessary code motion from translate_init.c.inc
> >
> > For instance, I don't immediately see why these changes are necessary. I
> > see that translate_init.c.inc already has some `#ifdef CONFIG_TCG`, so
> > why do we need to move a bunch of code into cpu.c instead of just adding
> > more code under ifdef CONFIG_TCG? (I'm not saying it's wrong, just trying to
> > understand the reasoning).
>
> There are 3 main reasons for this decision. The first is kind of silly, but when I read translate.c my mind jumped to translating machine code to TCG, and the amount of TCGv variables at the start reinforced this notion.
> The second was that both s390x and i386 removed it (translate.c) from compilation, so I had no good reason to doubt it.
> The last (and arguably most important) is that translate.c is many thousands of lines long (translate_init.c.inc alone was almost 11k). The whole point of disabling TCG is to speed up compilation and reduce the final file size, so I think it makes sense to remove that big file.
> And the final nail in the coffin is that at no point did it cross my mind to keep the init part of translation, but remove the rest
>
> Also, I'm not a fan of big ifdefs, because it's kinda hard to follow them when viewing code in vim. Adding that to already having a cpu.c file, where it makes sense (to me, at least) to add all CPU related functions, just sounded like a good idea.

I think those are all sound reasons; I think not compiling translate.c
for !tcg builds is the right choice.  We might, however, need to
"rescue" certain functions from there by moving them to another file
so they can be used by KVM code as well.

> > Is translate_init.c.inc intended to be TCG only? But then I see you
> > moved TCG-only functions out of it (ppc_fixup_cpu) and left not TCG-only
> > functions (gen_spr_generic).
>
> This is me misjudging what is TCG and what is not, mostly. I think that actually moving everything to cpu.c and adding ifdefs, or creating a cpu_tcg.c.inc or similar, would be the most sensible code motion, but every function I removed from translate gave me 3 new errors, at some point I felt like I should leave something behind otherwise we're compiling everything from TCG again, just in different files, so I tried to guess what was TCG and what was not (also, I really wanted the RFC out by the weekend, I _may_ have rushed a few choices).


> > > This moves all functions that start with gdb_* into target/ppc/gdbstub.c
> > > and creates a new function that calls those and is called by ppc_cpu_realize
> >
> > This looks like it makes sense regardless of disable-tcg, could we have
> > it in a standalone patch?
>
> Sure, I'll try and get it ready ASAP, and make sure I didn't miss one function before sending. Just a noob question... do I edit the patch manually to have it only contain the gdb code motion, or is there a way to move back to before I actually made the commit without needing to re-do the changes?
>
> Thomas, I'm adding you to this discussion since it sort of answers your message on the other one, about the functions used even in a KVM-only build.
>
> > IIRC you don't only have to exclude translate.c from the build, you also
> > have to separate translate_init.c.inc from it, i.e. turn
> > translate_init.c.inc into a proper .c file and get rid of the #include
> > "translate_init.c.inc" statement in translate.c, since many functions in the
> > translate_init.c.inc file are still needed for the KVM-only builds, too. So
> > maybe that's a good place to start as a first mini series.
>
> Now that I know that translate doesn't mean "translating to TCG", this idea makes more sense. My question is, is it a better option than the code motion I'm suggesting? From my quick check on the bits that I haven't touched it might, but at this point it's clear I'm very lost with what makes sense hahaha.
>
>
> Bruno Piazera Larsen
>
> Instituto de Pesquisas ELDORADO<http://clickemailmkt.eldorado.org.br/ls/click?upn=UPoxpeIcHnAcbUZyo7TTaswyiVb1TXP3jEbQqiiJKKGsxOn8hBEs5ZsMLQfXkKuKXZ7MVDg0ij9eG8HV4TXI75dBzDiNGLxQ8Xx5PzCVNt6TpGrzBbU-2Biu0o69X5ce-2FW-2FOk1uUipuK0fZnWXJEgbRw-3D-3DJY4T_wWk-2BG6VvNBoa1YzxYjhCdFS9IfANIaBzDSklR1NyyrKOI1wj0P-2BdBFcuO4FnHcsA1MyHu0ly1Yt3oDMp7KKdJPM68iKuI2jiRH5v4B0d8wf3chU3qy5n5iXWnW1QjSaNFHOgELzxaP-2FnesTeBgJ5dFkjH4f279sVQpOtyjw5xAqj34M6pgNRAxVvuXif4IWDcVzXg1FzfYlEfkKzr9vvpA3Hg8kitwMtlU3zwbQUBCgL30fQoJPcRPMGKyOY8RmoAlXNqTJYDYIvqmfnI7KLUvw6vKB5R-2B5q1FJRAzX7H-2BmF0NnDET6jMLuIqtCcVIch>
>
> Departamento Computação Embarcada
>
> Analista de Software Trainee
>
> Aviso Legal - Disclaimer<https://www.eldorado.org.br/disclaimer.html>

--
David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: Type: text/html, Size: 15048 bytes --]

^ permalink raw reply	[flat|nested] 24+ messages in thread
* [RFC PATCH 0/4] target/ppc: add disable-tcg option
@ 2021-04-09 15:19 Bruno Larsen (billionai)
  2021-04-09 15:19 ` [PATCH 1/4] target/ppc: Code motion required to build disabling tcg Bruno Larsen (billionai)
  0 siblings, 1 reply; 24+ messages in thread
From: Bruno Larsen (billionai) @ 2021-04-09 15:19 UTC (permalink / raw)
  To: qemu-devel
  Cc: lucas.araujo, lagarcia, luis.pires, fernando.valle, qemu-ppc,
	andre.silva, Bruno Larsen (billionai),
	matheus.ferst

This patch series aims to add the option to build without TCG for the
powerpc target. This RFC shows mostly the strategies employed when
dealing with compilation problems, and ask for input on the bits
we don't quite understand yet.

The first patch mostly code motion, as referenced in 2021-04/msg0717.
The second patch shows the 2 strategies we've considered, and hope to
get feedback on. The third patch contains the stubs we haven't decided
on how to deal with yet, but needed to exist to compile the project.
The final patch just changes the meson.build rules

Bruno Larsen (billionai) (4):
  target/ppc: Code motion required to build disabling tcg
  target/ppc: added solutions for problems encountered when building
    with disable-tcg
  target/ppc: Add stubs for tcg functions, so it build with disable-tcg
  target/ppc: updated build rules for disable-tcg option

 target/ppc/arch_dump.c          |   17 +
 target/ppc/cpu.c                |  859 +++++++++++++++++++++++
 target/ppc/cpu.h                |   15 +
 target/ppc/gdbstub.c            |  253 +++++++
 target/ppc/kvm.c                |   30 +
 target/ppc/kvm_ppc.h            |   11 +
 target/ppc/machine.c            |   33 +-
 target/ppc/meson.build          |   22 +-
 target/ppc/tcg-stub.c           |  139 ++++
 target/ppc/translate_init.c.inc | 1148 +------------------------------
 10 files changed, 1407 insertions(+), 1120 deletions(-)
 create mode 100644 target/ppc/tcg-stub.c

-- 
2.17.1



^ permalink raw reply	[flat|nested] 24+ messages in thread

end of thread, other threads:[~2021-04-27  1:58 UTC | newest]

Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-04-12 12:05 [PATCH 1/4] target/ppc: Code motion required to build disabling tcg Bruno Piazera Larsen
2021-04-12 13:56 ` Fabiano Rosas
2021-04-13  6:40 ` David Gibson
  -- strict thread matches above, loose matches on Subject: below --
2021-04-22 12:34 Bruno Piazera Larsen
2021-04-22 19:35 ` Fabiano Rosas
2021-04-23  0:08   ` David Gibson
2021-04-23 13:28     ` Fabiano Rosas
2021-04-27  1:29       ` David Gibson
2021-04-20 19:02 Bruno Piazera Larsen
2021-04-21  5:13 ` David Gibson
2021-04-19 14:40 Bruno Piazera Larsen
2021-04-20  1:20 ` David Gibson
2021-04-13 17:43 Bruno Piazera Larsen
2021-04-13 21:38 ` Fabiano Rosas
2021-04-14 12:04   ` Bruno Piazera Larsen
2021-04-14 20:05     ` Fabiano Rosas
2021-04-19  5:23   ` David Gibson
2021-04-14 19:37 ` Richard Henderson
2021-04-14 20:07   ` Bruno Piazera Larsen
2021-04-14 20:32     ` Richard Henderson
2021-04-19  5:21 ` David Gibson
2021-04-09 15:19 [RFC PATCH 0/4] target/ppc: add disable-tcg option Bruno Larsen (billionai)
2021-04-09 15:19 ` [PATCH 1/4] target/ppc: Code motion required to build disabling tcg Bruno Larsen (billionai)
2021-04-09 19:48   ` Fabiano Rosas
2021-04-12  4:34     ` David Gibson

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).