On Tue, Sep 19, 2017 at 01:40:02PM +0200, Richard Biener wrote: > > I think this would be very useful. Some of the regressions in type > > promotion comes from parameters/return values. ABI in some cases > > guarantees that they are properly extended but during type promotion > > we promote (or extend) leading to additional extensions.
These are the most visible unnecessary extensions, too, but perhaps not the most important ones (a function returns only once ;-) ) But yeah we should do the ABI-mandated extensions on gimple already. > 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. > > At RTL expansion we could then assert that PROMOTE_* handling is not > necessary for any register. I don't think we should do PROMOTE_MODE on gimple (it's not always a good thing on RTL either); just PROMOTE_FUNCTION_MODE and friends will be good though. > 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. > 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. At least on RTL it would help if we track which bits in which registers are do-not-care, similar to nonzero_bits. With that in place we can aggressively widen operations, which in turn helps remove extensions. Segher
