This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Segher


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]