This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PR68432 00/26] Handle size/speed choices for internal functions
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Bernd Schmidt <bschmidt at redhat dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, richard dot sandiford at arm dot com
- Date: Tue, 1 Dec 2015 13:16:55 +0100
- Subject: Re: [PR68432 00/26] Handle size/speed choices for internal functions
- Authentication-results: sourceware.org; auth=none
- References: <874mgajmo9 dot fsf at e105548-lin dot cambridge dot arm dot com> <565714FB dot 6080703 at redhat dot com> <87si3sequ0 dot fsf at e105548-lin dot cambridge dot arm dot com> <56572DDF dot 3070303 at redhat dot com> <87oaegenmz dot fsf at e105548-lin dot cambridge dot arm dot com> <565D8A8D dot 3030106 at redhat dot com>
On Tue, Dec 1, 2015 at 12:54 PM, Bernd Schmidt <bschmidt@redhat.com> wrote:
> On 11/26/2015 05:22 PM, Richard Sandiford wrote:
>>
>> Bernd Schmidt <bschmidt@redhat.com> writes:
>>
>>> I wish we'd taken some more time to think through the consequences of
>>> the original internal_fn patchset.
>>
>>
>> I don't think this PR shows that the approach was wrong.
>
>
> I think it does. Internal functions make a new assumptions, that expanders
> don't FAIL - but as we've now seen, they do. The optimize_size thing is
> reasonably easy to grep for and it looks like only i386 is affected, but
> have you looked at every expander in every port that could be used by an
> internal function to ensure it does not FAIL for a different reason?
Of course we are not sure. But I think the approach in the series is the only
reasonable one. I view the internal_fn support for optabs as a great way to
provide sth like instruction selection to GIMPLE with the goal to simplify
RTL expansion itself (which since quite some time cannot rely on seeing
"large" expressions anymore and with TER has the limitation of seeing
only some under the constraint TER and out-of-SSA operate).
> Is there a simple way to disable the entire internal_fn machinery and get us
> back to where we were in gcc-5, without taking out all the code immediately?
> That would give us time until next stage 1 to think through the issues.
Do you have even a guess as to how to approach the issue differently?
Yes, I think we can rip out uses of the new machinery quite easily but I don't
think we're at the point declaring failure yet.
Richard.
>
> Bernd