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