This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Use which_alternative in preparation-statements of define_insn_and_split
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: Jiangning Liu <Jiangning dot Liu at arm dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 23 Nov 2011 16:40:57 +0000
- Subject: Re: [RFC] Use which_alternative in preparation-statements of define_insn_and_split
- References: <000101cca7fe$83c35490$8b49fdb0$@liu@arm.com> <4ECAE4EF.8080102@redhat.com> <000b01cca8b7$689134d0$39b39e70$@liu@arm.com> <4ECBF2B5.1060403@redhat.com>
On 22/11/11 19:06, Richard Henderson wrote:
> On 11/21/2011 05:38 PM, Jiangning Liu wrote:
>> But I still want to know why we don't want to support this? I don't see any
>> GCC documentation saying not allowing this usage.
>
> Before reload, which_alternative doesn't make much sense, yet you compute it anyway. After reload, but for raw define_split, which_alternative doesn't make much sense, yet you compute it anyway.
>
> Now, either or both are fixable, but instead it seemed to me like maybe you were going down the wrong path entirely.
>
>
> r~
>
Plus extract_insn is a moderately expensive operation, given that we
have to scan all the alternatives in an insn to find the matching one.
I wouldn't have thought it was generally something we would want to do
on every split pattern we apply unless it is really needed.
R.