This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, ARM] correctly encode the CC reg data flow
- From: Bernd Edlinger <bernd dot edlinger at hotmail dot de>
- To: "Richard Earnshaw (lists)" <Richard dot Earnshaw at arm dot com>, Kyrill Tkachov <kyrylo dot tkachov at foss dot arm dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Cc: Ramana Radhakrishnan <ramana dot radhakrishnan at arm dot com>, Wilco Dijkstra <wilco dot dijkstra at arm dot com>
- Date: Tue, 10 Oct 2017 19:03:01 +0000
- Subject: Re: [PATCH, ARM] correctly encode the CC reg data flow
- Authentication-results: sourceware.org; auth=none
- Authentication-results: arm.com; dkim=none (message not signed) header.d=none;arm.com; dmarc=none action=none header.from=hotmail.de;
- References: <AM4PR0701MB2162CC520827145E96A75FE2E49E0@AM4PR0701MB2162.eurprd07.prod.outlook.com> <3f5e5538-5dd3-b416-904f-b87f115336fe@arm.com> <HE1PR0701MB21691E50EE349B95B4ADC4DBE4780@HE1PR0701MB2169.eurprd07.prod.outlook.com> <AM4PR0701MB216294C83C28945778C84345E4780@AM4PR0701MB2162.eurprd07.prod.outlook.com> <AM4PR0701MB2162B85CF846EC1E42D44F43E47F0@AM4PR0701MB2162.eurprd07.prod.outlook.com> <59AD5B44.2080509@foss.arm.com> <a55cfa36-bb99-3433-f99e-c261fbe5dac1@hotmail.de> <AM5PR0701MB26572C99CDF0198F38A7DB9BE4970@AM5PR0701MB2657.eurprd07.prod.outlook.com> <6f24b217-9131-6aef-0cdb-f9f26a538fe9@arm.com> <AM5PR0701MB26579A51C8FEC1232A3F607EE4970@AM5PR0701MB2657.eurprd07.prod.outlook.com> <dec6f985-c33f-957d-bd25-949a643130ee@arm.com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
On 10/09/17 15:02, Richard Earnshaw (lists) wrote:
> On 06/09/17 14:17, Bernd Edlinger wrote:
>> Index: gcc/doc/rtl.texi
>> ===================================================================
>> --- gcc/doc/rtl.texi (revision 251752)
>> +++ gcc/doc/rtl.texi (working copy)
>> @@ -2252,6 +2252,13 @@
>> If one of the operands is a constant, it should be placed in the
>> second operand and the comparison code adjusted as appropriate.
>>
>> +There may be exceptions to this rule if the mode @var{m} does not
>> +carry enough information for the swapped comparison operator, or
>> +if we try to detect overflow from the subtraction. That means, while
>> +0-X may overfow X-0 can never overflow. Under these conditions
s/overfow/overflow/
>> +a compare may have the constant expression at the first operand.
>> +Examples are the ARM negdi2_compare pattern and similar.
>> +
>> A @code{compare} specifying two @code{VOIDmode} constants is not valid
>> since there is no way to know in what mode the comparison is to be
>> performed; the comparison must either be folded during the compilation
>>
>
>
> Er, hold on. Comparisons don't 'overflow'. They compare two values and
> tell you something about their relationship. If A cmp B doesn't tell me
> the same basic things as B swapped(cmp) A, then the world will fall
> apart big time. So your documentation patch can't be right.
>
Hi Richard,
I think a CC-mode like CC_NCV is inherently unsymmetrical
which means that it does in general not provide enough information for
the swapped(cmp), and I think the truth is that the N-flag
is the sign of A-B, and V-flag is 1 if A-B overflows otherwise 0.
And if you ask for Branch if less-than that is Branch if N ^ V.
But in the moment I have no idea how to proceed.
Thanks
Bernd.