Re: [RFC] type promotion pass

[Jeff Law <law at redhat dot com>]

On 09/15/2017 10:19 AM, Segher Boessenkool wrote:
> On Fri, Sep 15, 2017 at 09:18:23AM -0600, Jeff Law wrote:
>> WORD_REGISTER_OPERATIONS works with PROMOTE_MODE.  The reason you can't
>> define WORD_REGISTER_OPERATIONS on aarch64 is because that the implicit
>> promotion is sometimes to 32 bits and sometimes to 64 bits.
>> WORD_REGISTER_OPERATIONS can't really describe that.
> 
> WORD_REGISTER_OPERATIONS isn't well-defined.
> 
> """
> @defmac WORD_REGISTER_OPERATIONS
> Define this macro to 1 if operations between registers with integral mode
> smaller than a word are always performed on the entire register.
> Most RISC machines have this property and most CISC machines do not.
> @end defmac
> """
> 
> Exactly what operations?  For almost all targets it isn't true for *all*
> operations.  Or no targets even, if you include rotate, etc.
> 
> For targets that have both 32-bit and 64-bit operations it is never true
> either.
> 
>> And I'm also keen on doing something with type promotion -- Kai did some
>> work in this space years ago which I found interesting, even if the work
>> didn't go forward.  It showed a real weakness.  So I'm certainly
>> interested in looking at Prathamesh's work -- with the caveat that if it
>> stumbles across the same issues as Kai's work that it likely wouldn't be
>> acceptable in its current form.
> 
> Doing type promotion too aggressively reduces code quality.  "Just" find
> a sweet spot :-)
> 
> Example: on Power, an AND of QImode with 0xc3 is just one insn, which
> actually does a SImode AND with 0xffffffc3.  This is what we do currently.
> A SImode AND with 0x000000c3 is two insns, or one if we allow it to write
> to CR0 as well ("andi."); same for DImode, except there isn't a way to do
> an AND with 0xffffffffffffffc3 in one insn at all.
> 
> unsigned char a;
> void f(void) { a &= 0xc3; };
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.

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.

jeff