On September 15, 2017 6:56:04 PM GMT+02:00, Jeff Law <l...@redhat.com> wrote:
>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.

I always thought we should start with those promotions that are done by RTL 
expansion according to PROMOTE_MODE and friends. The complication is that those 
promotions also apply to function calls and arguments and those are difficult 
to break apart from other ABI specific details. 

IIRC the last time we went over this patch I concluded a better first step 
would be to expose call ABI details on GIMPLE much earlier. But I may 
misremember here. 

Basically we couldn't really apply all promotions RTL expansion applies. One of 
my ideas with doing them early also was to simplify RTL expansion and 
especially promotion issues during SSA coalescing. 

Richard. 

>jeff

Reply via email to