Re: Hit a showstopper issue

[David Malcolm <dmalcolm@redhat.com>]

On Mon, 2015-06-15 at 16:54 -0400, David Malcolm wrote:
> 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)

I've filed a bug about the lack of a way to turn off the unreachable
block checking, as:
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66546