This is the mail archive of the
mailing list for the GCC project.
Re: implementation question
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Daniel Gutson <daniel dot gutson at tallertechnologies dot com>
- Cc: gcc Mailing List <gcc at gcc dot gnu dot org>
- Date: Mon, 5 May 2014 09:47:23 +0200
- Subject: Re: implementation question
- Authentication-results: sourceware.org; auth=none
- References: <CAF5HaEWgup1evKX=CLB0in6Eqe=Fd2pBoPPjMhMY6b3sLPk_UA at mail dot gmail dot com>
On Wed, Apr 30, 2014 at 7:49 PM, Daniel Gutson
> assuming the need to generate code in which
> almost everything is used 3x (e.g. 3x registers,
> 3 times data, etc.) for a specific purpose (*) for any
> given target,
> what would be the best way to implement it?
> (let's name this 3ple-voting behavior)
> a) as a forked backend target of each target (e.g.
> a 3ple-voting version of x86, a 3ple-voting version
> of ARM, etc.)
> b) as a late GIMPLE phase pluging?
> (*) The need comes from radiation bit-flipping
> tolerant software (the interested reader may
> check http://en.wikipedia.org/wiki/Single_event_upset).
> I am interested in SEUs affecting microprocessor registers
> and data.
> There is a voting technique in which
> the subjects under protection are triplicated, so on each operation,
> a check is performed whether the three are equal, or two are equal
> (in which case the third is fixed), or the three are distinct.
> Would a late GIMPLE phase plugin suffice?
> I think that I should manage to get the RTL tree
> with the necessary nodes triplicated and let
> the backend do its job, right? Or, am I forgetting
> any backend pass that may optimize/get screwed
> because of this?
It really depends on how "3x" should materialize in the end.
How do you triplicate ops with side-effects? If you only
triplicate ops without side-effects what is the sink that keeps
the duplicated ops live?