This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Regarding x86 'sete' instruction and its corresponding RTL
- From: Niranjan Hasabnis <nirhasabnis at gmail dot com>
- To: Eric Botcazou <ebotcazou at adacore dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Fri, 4 Apr 2014 13:06:36 -0400
- Subject: Re: Regarding x86 'sete' instruction and its corresponding RTL
- Authentication-results: sourceware.org; auth=none
- References: <CAD2ATQRsN7=4RKrHo6dCwS=a3jR0mJdTRkmqz6eOx9gJu8Yhrg at mail dot gmail dot com> <6603339 dot s6LlQ551EI at polaris>
Hi Eric,
Thank you for your reply. I referred to section 13.10, and the description
there does not precisely specify the result of comparison with CC register.
Yes, you are right that as per the description, comparison with CC may not
have anything to do with STORE_FLAG_VALUE. But it clearly says that
when the comparison fails, the result is 0. And this seems to be exactly
opposite of semantics of 'sete' instruction. So the problem is still
not solved.
Am I misreading something? Please let me know.
On Fri, Apr 4, 2014 at 3:58 AM, Eric Botcazou <ebotcazou@adacore.com> wrote:
>> ----------------------------------------------------------------
>> RTL: (set (reg:QI 0 ax)
>> (eq:QI (reg:CCZ 17 flags) (const_int 0)))
>>
>> Assembly: sete %al
>> ----------------------------------------------------------------
>>
>> Semantics of sete instruction is (as per Intel manual):
>> if zero flag = 1, (reg:QI ax) = 1
>> else (reg:QI ax) = 0
>>
>> Where as (I believe) RTL semantics seems to say that:
>> - if zero flag = 0, (reg:QI ax) = 1
>> else (reg:QI ax) = 0
>>
>> This is because 'eq' operator returns STORE_FLAG_VALUE when both
>> operands of 'eq' are equal. Otherwise, it returns 0. This is exactly
>> opposite of what assembly semantics is.
>
> No, that's wrong, the semantics of the comparison operators applied to the CC
> register have nothing to do with STORE_FLAG_VALUE (see manual section 13.10).
>
>
> Eric Botcazou
--
--------------------------
Regards,
Niranjan Hasabnis.