This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Wed, Oct 21, 2015 at 7:55 PM, Richard Henderson <rth@redhat.com> wrote:
> 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?

Ah, of course.  I tend to forget these issues.

Richard.

>
> r~


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]