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
