This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PR64164] drop copyrename, integrate into expand
- From: Andrew Pinski <pinskia at gmail dot com>
- To: Kyrill Tkachov <kyrylo dot tkachov at foss dot arm dot com>
- Cc: Alexandre Oliva <aoliva at redhat dot com>, Andreas Schwab <schwab at linux-m68k dot org>, Patrick Marlier <patrick dot marlier at gmail dot com>, Jeff Law <law at redhat dot com>, James Greenhalgh <James dot Greenhalgh at arm dot com>, "H.J. Lu" <hjl dot tools at gmail dot com>, Segher Boessenkool <segher at kernel dot crashing dot org>, Richard Biener <richard dot guenther at gmail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Christophe Lyon <christophe dot lyon at linaro dot org>, David Edelsohn <dje dot gcc at gmail dot com>, Eric Botcazou <ebotcazou at adacore dot com>
- Date: Tue, 18 Aug 2015 00:01:45 +0800
- Subject: Re: [PR64164] drop copyrename, integrate into expand
- Authentication-results: sourceware.org; auth=none
- References: <orio9cw10j dot fsf at livre dot home> <CAFiYyc3k9xh_6RGbTdHYOJ-aEmUWVeFRoWy=YzCHFDNSdtTXCA at mail dot gmail dot com> <orwpxqvqnp dot fsf at livre dot home> <20150723203112 dot GB27818 at gate dot crashing dot org> <CAMe9rOpR+2gPxo0tKaRPtcML_Q4=r-_=9iqk+_JZFPkM=eN=BQ at mail dot gmail dot com> <CAMe9rOpbLEyDexVJqJAFJ3W6o4AktNog-jwk2CY4GZkrmT+nfA at mail dot gmail dot com> <or4mkmhgc9 dot fsf at livre dot home> <CAMe9rOp=S5fu1N=i7waswCYqJeLBCrySqYdFYkVa7LV04vpQSg at mail dot gmail dot com> <CAMe9rOrq+ZBAg1nZ1twEcPqwBj4j9+XA+SXQJVWWzjfdvidjtw at mail dot gmail dot com> <or1tfkdjhj dot fsf at livre dot home> <20150810082355 dot GA31149 at arm dot com> <55C8BFC3 dot 3030603 at redhat dot com> <CAKQMxzRzMrGtf921vqXCno5uoBN+uzsnJ5wX2Twmvhp1ziAEcA at mail dot gmail dot com> <or37zlpujd dot fsf at livre dot home> <m2lhdd3pbe dot fsf at linux-m68k dot org> <or4mjz4l68 dot fsf at livre dot home> <m2k2sv8s21 dot fsf at linux-m68k dot org> <orr3n239nq dot fsf at livre dot home> <55D1A77B dot 4070105 at foss dot arm dot com>
On Mon, Aug 17, 2015 at 5:20 PM, Kyrill Tkachov
<kyrylo.tkachov@foss.arm.com> wrote:
> Hi Alexandre,
>
> On 17/08/15 03:56, Alexandre Oliva wrote:
>>
>> On Aug 16, 2015, Andreas Schwab <schwab@linux-m68k.org> wrote:
>>
>>> Alexandre Oliva <aoliva@redhat.com> writes:
>>>>
>>>> On Aug 15, 2015, Andreas Schwab <schwab@linux-m68k.org> wrote:
>>>>
>>>>> FAIL: gcc.target/aarch64/target_attr_crypto_ice_1.c (internal compiler
>>>>> error)
>>>>> In file included from
>>>>>
>>>>> /opt/gcc/gcc-20150815/gcc/testsuite/gcc.target/aarch64/target_attr_crypto_ice_1.c:4:0:
>>>>
>>>> Are you sure this is a regression introduced by my patch?
>>>
>>> Yes, it reintroduces the ICE.
>>
>> Ugh. I see this testcase was introduced very recently, so presumably it
>> wasn't present in the tree that James Greenhalgh tested and confirmed
>> there were no regressions.
>
>
> Yeah, I introduced it as part of the SWITCHABLE_TARGET
> work for aarch64. A bit of a mid-air collision :(
>
>> The hack in aarch64-builtins.c looks risky IMHO. Changing the mode of a
>> decl after RTL is assigned to it (or to its SSA partitions) seems fishy.
>> The assert is doing just what it was supposed to do. The only surprise
>> to me is that it didn't catch this unexpected and unsupported change
>> before.
>>
>> Presumably if we just dropped the assert in expand_expr_real_1, this
>> case would work just fine, although the unsignedp bit would be
>> meaningless and thus confusing, since the subreg isn't about a
>> promotion, but about reflecting the mode change that was made from under
>> us.
>>
>> May I suggest that you guys find (or introduce) other means to change
>> the layout and mode of the decl *before* RTL is assigned to the params?
>> I think this would save us a ton of trouble down the road. Just think
>> how much trouble you'd get if the different modes had different calling
>> conventions, alignment requirements, valid register assignments, or
>> anything that might make coalescing their SSA names with those of other
>> variables invalid.
>>
> I'm not familiar with the intricacies in this area but
> I'll have a look.
> Perhaps we can somehow re-layout the SIMD types when
> switching from a non-simd to a simd target...
> Can you, or Andreas please file a PR so we don't forget?
How does x86 handle this case? Because it should be handling this case somehow.
Thanks,
Andrew
>
> Thanks,
> Kyrill