> >> -----Original Message-----
> >> From: Richard Henderson <richard.hender...@linaro.org>
> >> Sent: Sunday, August 30, 2020 3:13 PM
> >> To: Taylor Simpson <tsimp...@quicinc.com>; qemu-devel@nongnu.org
> >> Cc: phi...@redhat.com; laur...@vivier.eu; riku.voi...@iki.fi;
> >> aleksandar.m.m...@gmail.com; a...@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
