Re: [0/7] Type promotion pass and elimination of zext/sext

[Richard Henderson <rth@redhat.com>]

On 10/21/2015 03:56 AM, Richard Biener wrote:
> On Wed, Oct 21, 2015 at 2:45 PM, Richard Biener
> <richard.guenther@gmail.com> wrote:
>> On Tue, Oct 20, 2015 at 10:03 PM, Kugan
>> <kugan.vivekanandarajah@linaro.org> wrote:
>>>
>>>
>>> On 07/09/15 12:53, Kugan wrote:
>>>>
>>>> This a new version of the patch posted in
>>>> https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00226.html. I have done
>>>> more testing and spitted the patch to make it more easier to review.
>>>> There are still couple of issues to be addressed and I am working on them.
>>>>
>>>> 1. AARCH64 bootstrap now fails with the commit
>>>> 94f92c36a83d66a893c3bc6f00a038ba3dbe2a6f. simplify-rtx.c is mis-compiled
>>>> in stage2 and fwprop.c is failing. It looks to me that there is a latent
>>>> issue which gets exposed my patch. I can also reproduce this in x86_64
>>>> if I use the same PROMOTE_MODE which is used in aarch64 port. For the
>>>> time being, I am using  patch
>>>> 0006-temporary-workaround-for-bootstrap-failure-due-to-co.patch as a
>>>> workaround. This meeds to be fixed before the patches are ready to be
>>>> committed.
>>>>
>>>> 2. vector-compare-1.c from c-c++-common/torture fails to assemble with
>>>> -O3 -g Error: unaligned opcodes detected in executable segment. It works
>>>> fine if I remove the -g. I am looking into it and needs to be fixed as well.
>>>
>>> Hi Richard,
>>>
>>> Now that stage 1 is going to close, I would like to get these patches
>>> accepted for stage1. I will try my best to address your review comments
>>> ASAP.
>>
>> Ok, can you make the whole patch series available so I can poke at the
>> implementation a bit?  Please state the revision it was rebased on
>> (or point me to a git/svn branch the work resides on).
>>
>>> * Issue 1 above (AARCH64 bootstrap now fails with the commit) is no
>>> longer present as it is fixed in trunk. Patch-6 is no longer needed.
>>>
>>> * Issue 2 is also reported as known issue
>>>
>>> *  Promotion of PARM_DECLs and RESULT_DECLs in IPA pass and patterns in
>>> match.pd for SEXT_EXPR, I would like to propose them as a follow up
>>> patch once this is accepted.
>>
>> I thought more about this and don't think it can be made work without a lot of
>> hassle.  Instead to get rid of the remaining "badly" typed registers in the
>> function we can key different type requirements on a pass property
>> (PROP_promoted_regs), thus simply change the expectation of the
>> types of function parameters / results according to their promotion.
>
> Or maybe we should simply make GIMPLE _always_ adhere to the ABI
> details from the start (gimplification).  Note that this does not only involve
> PROMOTE_MODE.  Note that for what GIMPLE is concerned I'd only
> "lower" passing / returning in registers (whee, and then we have
> things like targetm.calls.split_complex_arg ... not to mention passing
> GIMPLE memory in registers).
>
> Maybe I'm shooting too far here in the attempt to make GIMPLE closer
> to the target (to expose those redundant extensions on GIMPLE) and
> we'll end up with a bigger mess than with not doing this?

I'm leary of building this in as early as gimplification, lest we get into 
trouble with splitting out bits of the current function for off-loading.  What 
happens when the cpu and gpu have different promotion rules?


r~