This is the mail archive of the 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 4:58 PM, Jeff Law <> 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).


> Jeff

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