On 02/26/2018 08:44 AM, Martin Sebor wrote: > > Folding things to MEM_REF (or rather, folding them too early) > makes all kinds of analysis harder: not just warnings but even > optimization. I've raised a whole slew of bugs for the strlen > pass alone where folding string functions to MEM_REF defeats > useful downstream optimizations. Making strlen (and all other > passes that might benefit from the original detail) work hard > to deal with MEM_REF isn't a good design solution. It forces > the complexity that MEM_REF is meant to remove back into its > clients. Worse, because of the loss of detail, the results > are unavoidably suboptimal (at least for certain kinds of > analyses). I haven't looked specifically at the MEM_REF folding, but I wouldn't be surprised to find cases where deferral ultimately results in regressions.
When to fold & lower is a hard problem. There is a constant tension between trying to fold early as it often leads to generally better code vs folding later which may help other sets of code, particularly when folding results in an inability to recover data. There generally is not an optimal solution to these problems; we have to take a pragmatic approach. So if you can defer and not regress, then by all means propose patches. But I think you'll find that to defer means you have to beef up stuff later in the pipeline. jeff
