This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [GNU Tools Cauldron 2014] A proposal for type-safe RTL
- From: David Malcolm <dmalcolm at redhat dot com>
- To: Prathamesh Kulkarni <bilbotheelffriend at gmail dot com>
- Cc: gcc <gcc at gcc dot gnu dot org>, Maxim Kuvyrkov <maxim dot kuvyrkov at linaro dot org>
- Date: Wed, 06 Aug 2014 10:01:25 -0400
- Subject: Re: [GNU Tools Cauldron 2014] A proposal for type-safe RTL
- Authentication-results: sourceware.org; auth=none
- References: <CAJXstsCAV_NOa3AwwT9s29X9mkDNyKdtsO4TTNkQKyoO7VHSNA at mail dot gmail dot com>
On Tue, 2014-08-05 at 03:20 +0530, Prathamesh Kulkarni wrote:
> Hi,
> Please find attached my notes on "A proposal on type-safe RTL".
> I would be grateful if you would review it for me.
>
> Thanks,
> Prathamesh
>
> A proposal for type-safe RTL
>
> Author: David Malcolm
>
> RTL is a low-level intermediate langauge used in GCC to perform
> machine-dependent optimziations and
> code generation. The current RTL data strucutures (rtx), is not
> type-safe, and type checking
> cannot be performed during build-time.
Not quite: there is an option ENABLE_RTL_CHECKING to do this, but it's
so expensive that AIUI it's rarely used.
> The motivation of this project is to make RTL type-safe, so that type
> errors can be caught at build-time,
> and to increase readability of code that operates on RTL.
Note that to "make RTL type-safe" could be ambiguous: I'm looking at
typesafety of GCC's own types, rather than the user's. My plans
involving making a distinction between RTL instructions vs expressions
i.e. the types of GCC's own implementation. AIUI, by the time we reach
rtx most of the higher-level types in the *code being compiled* don't
really exist anymore; we're just working with bit patterns of varying
lengths - and it's not my intention to change the latter.
> Representation using C++ class heirarchy:
> Currently rtx is used to represent all RTL-types - instructions,
> expressions, etc.
> The idea is to convert rtx into C++ class heirarchy, with rtx_def
> being base type, rtx_insn representing
> instructions, etc. Using C++ class heirarchy makes it type-safe and
> enables type-errors to be caught at
> build-time
>
> Planned Class herirarchy:
>
> class rtx_def;
> class rtx_insn; /* (INSN_P (X) || NOTE_P (X)
> || JUMP_TABLE_DATA_P (X) || BARRIER_P (X)
> || LABEL_P (X)) */
> class rtx_real_insn; /* INSN_P (X) */
> class rtx_debug_insn; /* DEBUG_INSN_P (X) */
> class rtx_nonjump_insn; /* NONJUMP_INSN_P (X) */
> class rtx_jump_insn; /* JUMP_P (X) */
> class rtx_call_insn; /* CALL_P (X) */
> class rtx_jump_table_data; /* JUMP_TABLE_DATA_P (X) */
> class rtx_barrier; /* BARRIER_P (X) */
> class rtx_code_label; /* LABEL_P (X) */
> class rtx_note; /* NOTE_P (X) */
>
> Patch-series can be seen at:
> http://dmalcolm.fedorapeople.org/gcc/patch-backups/rtx-classes/
>
> Merge proposal for next GCC release:
> - rtx_insn to represent RTL "instructions", subclass of rtx_def.
> rtx_insn would be a big gain in type-safety.
(nods) I've been cleaning up and testing the patch series (currently
at 236 patches) and hope to post it for review later today.