On Tue, Sep 19, 2017 at 4:58 PM, Jeff Law <l...@redhat.com> wrote: > On 09/19/2017 05:40 AM, Richard Biener wrote: > >>> We might also need some way of having gimple statements that can >>> convert (or promote to the type without extensions) just to keep the >>> gimple type system happy. >> >> Yes, one of the "issues" is GIMPLE doesn't have subregs (I think that's >> a good thing). So we end up with truncations all over the place, IIRC >> mostly for calls and inline asms. > Right. Let's not go down the path of adding subregs or something > similar to gimple. The benefits are minimal and it adds a level of > complexity that everything would have to deal with. We've seen the > level of pain that brings to RTL. > > We're far better off doing what we can to expose the conversions, > eliminate those which are redundant within the gimple typesystem, then > at the gimple/RTL border eliminating those which are redundant due to > the way the processor works. > >> As said I originally saw the promotion as lowering phase where basically >> all GIMPLE registers have to adhere to the targets promotion rules >> (and we'd enforce that in verify_gimple). There are passes / match.pd >> patterns that would like to narrow things again and we'd need to avoid >> those in some way, like with a curr_properties & PROP_lreg property or so. > Agreed. The target promotions, particularly WRT > WORD_REGISTER_OPERATIONS and ABI are the biggest missing piece here. > >> >> At RTL expansion we could then assert that PROMOTE_* handling is not >> necessary for any register. >> >> This means we should have exposed all target required explicit sign- and >> zero-extensions and can optimize those at the GIMPLE level. >> >> Having a general promotion pass that doesn't allow us to assert everything >> is promoted or whose effect is quickly undone doesn't look too useful to me. > Agreed. > > >> Instead if we think we can't have the full cake we should concentrate on >> a sign-/zero-extension removal pass that makes promotion explicit only >> where it will remove extensions in the end. Such pass would likely >> build ontop the VRP pass infrastructure but doing on-demand computation >> on promoted types starting from stmts that require sign-/zero-extension >> at the end. > Hmm, I wonder if we could build this on top of Andrew's infrastructure. > Building ranges as part of walking the use-def chains seems like we'd > have 90% of the infrastructure.
I've yet got to see it ;) There's also still my half-ass patch sent to do sth like that using the existing VRP workers. Whether on-demand is good or a full sweep over the function is better remains to be seen for this case. Of course on-demand would alllow for easier switching of the "interesting type" (not sure if you can trick "Andrews infrastructure" to perform range propagation on widened types easily - it's quite trivial with the VRP workers). Richard. > Jeff
