This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] type promotion pass
On Mon, Sep 18, 2017 at 4:30 AM, Kugan Vivekanandarajah
<kugan.vivekanandarajah@linaro.org> wrote:
> Hi Richard,
>
> On 16 September 2017 at 06:12, Richard Biener
> <richard.guenther@gmail.com> wrote:
>> On September 15, 2017 6:56:04 PM GMT+02:00, Jeff Law <law@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.
>
> 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.
Yes, one of the "issues" is GIMPLE doesn't have subregs (I think that's
a good thing). So we end up with truncations all over the place, IIRC
mostly for calls and inline asms.
As said I originally saw the promotion as lowering phase where basically
all GIMPLE registers have to adhere to the targets promotion rules
(and we'd enforce that in verify_gimple). There are passes / match.pd
patterns that would like to narrow things again and we'd need to avoid
those in some way, like with a curr_properties & PROP_lreg property or so.
At RTL expansion we could then assert that PROMOTE_* handling is not
necessary for any register.
This means we should have exposed all target required explicit sign- and
zero-extensions and can optimize those at the GIMPLE level.
Having a general promotion pass that doesn't allow us to assert everything
is promoted or whose effect is quickly undone doesn't look too useful to me.
Instead if we think we can't have the full cake we should concentrate on
a sign-/zero-extension removal pass that makes promotion explicit only
where it will remove extensions in the end. Such pass would likely
build ontop the VRP pass infrastructure but doing on-demand computation
on promoted types starting from stmts that require sign-/zero-extension
at the end.
Richard.
> 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
>>