Hi Richard,
On 16 September 2017 at 06:12, Richard Biener
wrote:
> On September 15, 2017 6:56:04 PM GMT+02:00, Jeff Law 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 0xffc3. This is what we do
>>currently.
>>> A SImode AND with 0x00c3 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 0xffc3 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.
I think this would be very useful. Some of the regressions in type
promotion comes from parameters/return values. ABI in some cases
guarantees that they are properly extended but during type promotion
we promote (or extend) leading to additional extensions.
We might also need some way of having gimple statements that can
convert (or promote to the type without extensions) just to keep the
gimple type system happy.
Thanks,
Kugan
>
> 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
>
