qemu-devel
[Top][All Lists]
Advanced

[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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]