This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFA: cache enabled attribute by insn code
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Christophe Lyon <christophe dot lyon at linaro dot org>, Jeff Law <law at redhat dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, "rsandifo at linux dot vnet dot ibm dot com" <rsandifo at linux dot vnet dot ibm dot com>
- Date: Tue, 27 May 2014 17:01:06 +0100
- Subject: Re: RFA: cache enabled attribute by insn code
- Authentication-results: sourceware.org; auth=none
- References: <87k39gkgq0 dot fsf at talisman dot default> <537B95E9 dot 1010203 at redhat dot com> <87iop0i13e dot fsf at talisman dot default> <537F9126 dot 5080904 at redhat dot com> <CAKdteOaYVgFZg5aUWUj9K7LPgmiGoT3iFiiaVbc-eSUKv22HCQ at mail dot gmail dot com> <87zji31fh7 dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <5384AC23 dot 40701 at arm dot com> <20140527152726 dot GO10386 at tucnak dot redhat dot com> <5384B1DD dot 5080601 at arm dot com> <20140527155010 dot GP10386 at tucnak dot redhat dot com>
On 27/05/14 16:50, Jakub Jelinek wrote:
> On Tue, May 27, 2014 at 04:40:13PM +0100, Richard Earnshaw wrote:
>> <quote>
>> The @code{enabled} insn attribute may be used to disable certain insn
>> alternatives for machine-specific reasons.
>> <quote>
>>
>> The rest of the text just says what happens when this is done and then
>> gives an example usage. It doesn't any time, either explicitly or
>> implicitly, say that this must be a static choice determined once-off at
>> run time.
>
> It says:
> "This definition should be based on other insn attributes and/or target flags."
<pedantry>
- It only says *should*, not *must*. "Should" can imply a
recommendation, not a requirement.
- It only says *based on*, not *solely based on*. Based on implies that
other information might be involved as well, without limitation.
</pedantary>
> where from what I understand Andreas originally meant was that the other
> insn attributes would be again based on target flags or other such insn
> attributes. Yeah, it explicitly rules out just basing the enabled attribute on
> the operands, arm uses just another attribute based on the operands there,
> but it still goes against the intent of the attribute, and is definitely a
> nightmare for the register allocator.
> Decisions based on the operands should be through constraints.
>
> From what I can see, arm uses it just on a single insn, so I'd say it
> shouldn't be a big deal to rewrite it.
>
Pedantry aside, I'm not against making such a restriction; but it is a
new restriction that isn't explictly stated in the documentation today.
R.