On Fri, Sep 15, 2017 at 12:13:39PM -0500, Segher Boessenkool wrote:
> On Fri, Sep 15, 2017 at 10:56:04AM -0600, Jeff Law wrote:
> > Yes, these are some of the things we kicked around. One of the most
> > interesting conclusions was that for these target issues we'd really
> > like a target.pd file to handle this class of transformations just prior
> > to rtl expansion.
>
> But often combine will need to know about which bits you actually care
> about (and other passes too, but combine is the biggie).
>
> > Essentially early type promotion/demotion would be concerned with cases
> > where we can eliminate operations in a target independent manner and
> > narrow operands as much as possible. Late promotion/demotion would deal
> > with stuff like the target's desire to work on specific sized hunks in
> > specific contexts.
> >
> > I'm greatly oversimplifying here. Type promotion/demotion is fairly
> > complex to get right.
>
> Yeah :-(
>
> Maybe the best thing is to promote really early, but to keep track of which
> bits matter. And then adjust some passes to take that into account. Not a
> trivial amount of work.
Is type promotion actually what we want to do early? I'd think type
demotion is what better canonicalizes the IL and removes redundant
operations (e.g. those affecting only high bits if we only care about low
bits).
Then another spot is the vectorizer, where we ideally should be promoting or
demoting types such that we have as few different type bitsizes in the loop.
And then somewhere late we should in a target driven way decide what is the
optimal type to perform operations (promote or leave unpromoted).
Jakub
