[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 02/10] target/hexagon: import README for idef-parser

From: Richard Henderson
Subject: Re: [PATCH v2 02/10] target/hexagon: import README for idef-parser
Date: Thu, 25 Feb 2021 12:20:53 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

On 2/25/21 7:18 AM, Alessandro Di Federico wrote:
> +Now let's have a quick look at the generated code, line by line.
> +
> +::
> +
> +   tcg_gen_movi_i32(RdV, 0);
> +
> +This code starts by initializing ``RdV``, since reading from that register
> +without initialization will cause a segmentation fault by QEMU.  This is 
> emitted
> +because a declaration of the ``RdV`` register was parsed, but no reading of 
> the
> +``RdV`` register was found.

This is odd, as is the description of why.  Yes, if RdV is read without
initialization, TCG middle-end will abort (at least with --enable-debug-tcg
enabling the assertions).  But you've just said that "no reading" was found.
So why did you perform this dummy initialization, which will be eliminated 

> +Another example that highlight the limitation of the flex/bison parser can be
> +found even in the add operation we already saw:
> +
> +::
> +
> +   TCGv_i32 tmp_0 = tcg_temp_new_i32();
> +   tcg_gen_add_i32(tmp_0, RsV, RtV);
> +   tcg_gen_mov_i32(RdV, tmp_0);
> +
> +The fact that we cannot directly use ``RdV`` as the destination of the sum 
> is a
> +consequence of the syntax-driven nature of the parser. In fact when we parse 
> the
> +assignment, the ``rvalue`` token, representing the sum has already been 
> reduced,
> +and thus its code emitted and unchangeable. We rely on the fact that QEMU 
> will
> +optimize our code reducing the useless move operations and the relative
> +temporaries.

So, I take it from this that you're emitting tcg directly from within the
parser, and not generating any kind of abstract syntax tree?

A little disappointing, but not critical.  Even what you have is an improvement.

> +A more radical improvement will use the parser, not to generate directly the
> +tinycode generator code, but to generate an intermediate representation like 
> the
> +LLVM IR, which in turn could be compiled using the clang TCG backend.

I sincerely doubt this is worth it.


reply via email to

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