[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: |
Richard Henderson |
Subject: |
Re: [RFC PATCH v3 30/34] Hexagon (target/hexagon) TCG for instructions with multiple definitions |
Date: |
Mon, 31 Aug 2020 10:29:15 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 |
On 8/31/20 10:08 AM, Taylor Simpson wrote:
> 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.
Except, at some point, one has to debug this code.
If the code is unreadable, how do you figure out what's broken?
> 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
Yes please.
> I addition, there other things I should do if we want the generated files to
> be more readable
> - Indent the code
Helpful, yes.
I wouldn't worry about nested statements within the *.def files too much,
except to put each ";" terminated statement on a new line, so that gdb's step
command goes to the next statement instead of skipping everything all at once.
> - Only generate one of the fGEN_TCG_<tag> or gen_helper_<tag>
That would be part of "skip the instructions that have overrides", would it not?
> - Generate the declaration of the generate_<tag> function instead of just the
> body
I'm not quite sure what this means.
Aren't the "generate_<tag>" functions private to genptr.c? Why would we need a
separate declaration of them, as opposed to just a definition?
r~
- [RFC PATCH v3 22/34] Hexagon (target/hexagon) generator phase 3 - C preprocessor for decode tree, (continued)
- [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, 2020/08/31
- Re: [RFC PATCH v3 30/34] Hexagon (target/hexagon) TCG for instructions with multiple definitions,
Richard Henderson <=
- 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