This is the mail archive of the
mailing list for the GCC project.
Re: [RFC] type promotion pass
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.