Re: [RFC PATCH v3 30/34] Hexagon (target/hexagon) TCG for instructions with multiple definitions

[Richard Henderson]

On 8/30/20 2:30 PM, Taylor Simpson wrote:
> 
> 
>> -----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.


r~