Annoyance with new integer promotion deprecations

H. S. Teoh hsteoh at quickfur.ath.cx
Wed Feb 7 00:15:09 UTC 2018


On Tue, Feb 06, 2018 at 12:23:02PM -0800, Walter Bright via Digitalmars-d wrote:
> On 2/5/2018 10:08 PM, H. S. Teoh wrote:
> > IMO, we should extend this past just one statement. It would lead to
> > more possibilities for optimizations and possibly other features
> > too.  Though I understand that Walter has reservations about doing
> > this for some reason.
> 
> What you're asking for is data flow analysis. DFA's effectiveness is
> definitely a quality of implementation thing. But if you want to have
> a successful compile depend on DFA, then you've got to define in the
> Specification exactly what DFA is done.
> 
> The next problem is DFA is a complex thing. This is why DFA is done on
> the vastly simplified and canonicalized intermediate code, not the
> ASTs. With dmd's inliner, I made the mistake of doing inlining of the
> ASTs (other compilers do it with the intermediate code). This was a
> major error, and has led to all kinds of peculiar bugs and
> shortcomings. I'm not going to make that mistake again.

What are the chances for inlining to be moved back to the IR? Or is that
not worth contemplating because it's too huge / disruptive of a project?


> Doing DFA for VRP means doing it on the ASTs.
> 
> I know what you're asking for sounds simple enough. But it ain't.

Is it possible to retain VRP information in the IR? Or is that far too
late?


T

-- 
Freedom of speech: the whole world has no right *not* to hear my spouting off!


More information about the Digitalmars-d mailing list