Re: Interest in integer auto-upcasting pass for normalization and optimization?

[Albert Cohen <Albert.Cohen@inria.fr>]

Richard Guenther wrote:
> On Sat, May 9, 2009 at 10:42 PM, Richard Guenther
> <richard.guenther@gmail.com> wrote:
>> On Sat, May 9, 2009 at 10:07 PM, Albert Cohen <Albert.Cohen@inria.fr> wrote:
>>> Sebastian Pop and I have been discussing the option of designing a new pass,
>>> based on vrp, to normalize integer types towards a canonical supertype
>>> typically a machine word, equivalent to signed long, or to truncate to a
>>> smaller-size word when it makes sense. This would be a very simple pass (on
>>> top of not-so-simple vrp), but arguably a quite regression-prone one as well
>>> (due to aliases/escape and common C standard violations).
>>>
>>> The pass could be parameterized with three different objectives, depending
>>> on where it is scheduled in the pass manager.
>>>
>>> (1) canonicalize to the supertype aggressively, to facilitate the
>>> application of further passes like autovect which require very precise
>>> understanding of the type conversions;
>>> (2) compress the types to increase vectorization factor and reduce register
>>> pressure (assuming the target supports sub-word register allocation with
>>> register aliases);
>>> (3) optimize the types to minimize the dynamic number of casts that result
>>> in actual ASM instructions.
>>>
>>> Graphite and the vectorizer would clearly benefit from such a pass, at least
>>> if it implemented objective (1).
>>>
>>> I wonder if some of this is already implemented somewhere, or if someone
>>> played with it in the past, or is interesting in contributing.
>>>
>>> Nothing is planned yet on our side, and temporary fixes exist in the short
>>> term (as far as Graphite and the vectorizer are concerned), but it would
>>> potentially be of great help.
>> This is certainly one useful transformation based on value-range information.
>> The choice of a canonical type is of course at least target dependent.
> 
> This btw. can at least partly replace the SEE (or the missed ZEE) pass.

We'll start by looking at what is done there, thanks. Not sure when we 
will start, though...

>> I suppose you want to do this on register variables only?  Did you think about
>> promoting function arguments and returns as well as part of an IPA pass?
>>
>> I don't understand how register variable promotion/demotion will help graphite
>> though - I had the impression graphite can only work on memory.  No?

It will work at a higher level: graphite generates new loops with brand 
new induction variables, whose types are canonical (cf. your earlier 
canonical type suggestion). No way those canonical types can match 
preexisting induction variables in general. This causes a lot of casts 
in some cases, and confuses the vectorizer, and may even generate nasy 
SE/ZE instructions eventually.

Thank you,
Albert