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: Interest in integer auto-upcasting pass for normalization and optimization?

Richard Guenther wrote:
On Sat, May 9, 2009 at 10:42 PM, Richard Guenther
<> wrote:
On Sat, May 9, 2009 at 10:07 PM, Albert Cohen <> 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,

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