Re: Hit a showstopper issue

[David Malcolm <dmalcolm@redhat.com>]

On Mon, 2015-06-15 at 21:25 +0100, Dibyendu Majumdar wrote:
> On 15 June 2015 at 20:32, Dibyendu Majumdar <mobile@majumdar.org.uk> wrote:
> > I apologize for bringing in LLVM comparison again - but they have a
> > model that seems to work just right. Basically the LLVM
> > verifier/compiler will detect invalid blocks and conrol flow - which
> > is more important for debugging purposes. Usually a bug will manifest
> > itself in some corruption in the control flow - e.g. variable not
> > accessible in all code paths and such - LLVM detects these and raises
> > errors.
> 
> Of course LLVM's IR is SSA form so that probably makes it easier to
> validate the control flow. They described this as 'well formed'-ness -
> the verifier detects if the code is  well-formed and complains if 'the
> definition of %x does not dominate all of its uses'. My understanding
> is that the IR you are working with is not SSA-form so this type of
> validation may not be possible...

Yes: the IR exposed by the libgccjit API is not SSA-form.  The optimizer
does use SSA-form internally.

I think my opinion at the time was that forcing users to create phi
nodes was unnecessary work for them; let the API do it automatically,
internally.   I don't know if the loss of this kind of validation is a
show-stopper; it feels to me more like a fussy API that the user has to
do extra work to appease.  But I could be wrong.

> In any case a warning about unreachable bocks may be more appropriate
> than errors.

FWIW I've experimented in the past with turning on warnings about
uninitialized vars, so maybe we need an API setting for validations,
with each validation having a tri-state:
  * perform validation, as error
  * perform validate, as warnings to stderr
  * don't validate

(thinking aloud here)

Dave