[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [RFC PATCH v3 30/34] Hexagon (target/hexagon) TCG for instructions w
From: |
Taylor Simpson |
Subject: |
RE: [RFC PATCH v3 30/34] Hexagon (target/hexagon) TCG for instructions with multiple definitions |
Date: |
Mon, 31 Aug 2020 17:08:34 +0000 |
> >> -----Original Message-----
> >> From: Richard Henderson <richard.henderson@linaro.org>
> >> Sent: Sunday, August 30, 2020 3:13 PM
> >> To: Taylor Simpson <tsimpson@quicinc.com>; qemu-devel@nongnu.org
> >> Cc: philmd@redhat.com; laurent@vivier.eu; riku.voipio@iki.fi;
> >> aleksandar.m.mail@gmail.com; ale@rev.ng
> >> Subject: Re: [RFC PATCH v3 30/34] Hexagon (target/hexagon) TCG for
> >> instructions with multiple definitions
> >>
> >> On 8/30/20 12:48 PM, Taylor Simpson wrote:
> >>> I'll add the following comment to indicate what's going on
> >>>
> >>> /*
> >>> * Each of the generated helpers is wrapped with #ifndef
> >> fGEN_TCG_<tag>.
> >>> * For example
> >>> * #ifndef fGEN_TCG_A2_add
> >>> * DEF_HELPER_3(A2_add, s32, env, s32, s32)
> >>> * #endif
> >>> * We include gen_tcg.h here to provide definitions of fGEN_TCG for
> any
> >> instructions that
> >>> * are overridden.
> >>> *
> >>> * This prevents unused helpers from taking up space in the executable.
> >>> */
> >>
> >> Ah, hum. Well.
> >>
> >> How about we figure out a way to communicate to the generator scripts
> >> which
> >> functions have been implemented "directly", and don't need to be
> >> generated at all?
> >>
> >> I don't see why we have to wait until the c preprocessor to remove this
> >> unused
> >> code, and the less we have of it, the better.
> >>
> >
> > A few reasons
> > - Makes it easy to override instruction helpers. All one has to do is
> > #define
> fGEN_TCG_<tag>.
>
> If the generator can examine, say, genptr_override.c.inc, then you don't
> even
> have to add a #define. Just add the code.
>
> Perhaps something like
>
> DEFINE_FGEN(tag)
> {
> // some code
> }
>
> where DEFINE_FGEN expands to the appropriate function declaration. The
> generator then need only grep '^DEFINE_FGEN' and extract the list of
> overridden
> tags.
>
>
> > - When debugging the override, sometimes you want to quickly revert back
> to the helper. Or if you've written a bunch of overrides in one shot and then
> find that a test case is failing, you can binary search which one to turn off
> and
> get the test to pass. This is the one with the bug to fix.
>
> No difference there, just binary searching on different text.
>
> > - Reduces time for an incremental build. When we add or delete an
> override, we don't have to re-run the generator.
>
> About this I care not at all. I can't imagine that more than fractions of a
> second are at stake.
I can modify the generator to skip instructions with overrides.
There are some assumptions here I'd like to clarify. When I started this
discussion, there seemed to be general resistance to the concept of a
generator. Because of this, I made the generator as simple as possible and
pushed the complexity and optimization into code that consumes the output of
the generator. Also, I assumed people wouldn't read the output of the
generator, so I didn't focus on making it readable.
Now, it sounds like my assumptions were not correct. You pointed out two
things to do in the generator
- Expand the macros inline
- Skip the instructions that have overrides
I addition, there other things I should do if we want the generated files to be
more readable
- Indent the code
- Only generate one of the fGEN_TCG_<tag> or gen_helper_<tag>
- Generate the declaration of the generate_<tag> function instead of just the
body
Thoughts?
Thanks,
Taylor
- [RFC PATCH v3 21/34] Hexagon (target/hexagon) generator phase 2 - generate header files, (continued)
- [RFC PATCH v3 21/34] Hexagon (target/hexagon) generator phase 2 - generate header files, Taylor Simpson, 2020/08/18
- [RFC PATCH v3 22/34] Hexagon (target/hexagon) generator phase 3 - C preprocessor for decode tree, Taylor Simpson, 2020/08/18
- [RFC PATCH v3 32/34] Hexagon (linux-user/hexagon) Linux user emulation, Taylor Simpson, 2020/08/18
- [RFC PATCH v3 30/34] Hexagon (target/hexagon) TCG for instructions with multiple definitions, Taylor Simpson, 2020/08/18
- Re: [RFC PATCH v3 30/34] Hexagon (target/hexagon) TCG for instructions with multiple definitions, Richard Henderson, 2020/08/28
- RE: [RFC PATCH v3 30/34] Hexagon (target/hexagon) TCG for instructions with multiple definitions, Taylor Simpson, 2020/08/30
- Re: [RFC PATCH v3 30/34] Hexagon (target/hexagon) TCG for instructions with multiple definitions, Richard Henderson, 2020/08/30
- RE: [RFC PATCH v3 30/34] Hexagon (target/hexagon) TCG for instructions with multiple definitions, Taylor Simpson, 2020/08/30
- Re: [RFC PATCH v3 30/34] Hexagon (target/hexagon) TCG for instructions with multiple definitions, Richard Henderson, 2020/08/30
- RE: [RFC PATCH v3 30/34] Hexagon (target/hexagon) TCG for instructions with multiple definitions,
Taylor Simpson <=
- Re: [RFC PATCH v3 30/34] Hexagon (target/hexagon) TCG for instructions with multiple definitions, Richard Henderson, 2020/08/31
- RE: [RFC PATCH v3 30/34] Hexagon (target/hexagon) TCG for instructions with multiple definitions, Taylor Simpson, 2020/08/31
- Re: [RFC PATCH v3 30/34] Hexagon (target/hexagon) TCG for instructions with multiple definitions, Richard Henderson, 2020/08/31
- RE: [RFC PATCH v3 30/34] Hexagon (target/hexagon) TCG for instructions with multiple definitions, Taylor Simpson, 2020/08/31
- Re: [RFC PATCH v3 30/34] Hexagon (target/hexagon) TCG for instructions with multiple definitions, Richard Henderson, 2020/08/31
[RFC PATCH v3 33/34] Hexagon (tests/tcg/hexagon) TCG tests, Taylor Simpson, 2020/08/18
Re: [RFC PATCH v3 00/34] Hexagon patch series, no-reply, 2020/08/18
Re: [RFC PATCH v3 00/34] Hexagon patch series, Richard Henderson, 2020/08/28