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. Jeff
