This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RTL Expand pass - Difference in float and int datatypes


On 9 February 2011 22:28, Richard Guenther <richard.guenther@gmail.com> wrote:
> On Wed, Feb 9, 2011 at 5:55 PM, Anitha Boyapati
> <anitha.boyapati@gmail.com> wrote:
>> On 9 February 2011 20:34, Ian Lance Taylor <iant@google.com> wrote:
>>
>>>> I would like to know what prompts gcc to decide if "le" can be used in
>>>> the expand pass rather than "gt" operator. Or more precisely why it
>>>> differs incase of float.
>>>
>>> The choice of LE when using int is just a happenstance of the way that
>>> gcc generates code. ?When gcc comes to RTL generation it happens to be
>>> looking at an if statement that falls through on true and branches on
>>> else. ?So it flips the condition to branch on true (in
>>> do_compare_rtx_and_jump). ?The use of volatile doesn't affect this: it
>>> will still only load the variables precisely as described in the
>>> program.
>>>
>>> The condition can not be flipped for float because that would be an
>>> invalid transformation if one of the values is NaN.
>>>
>>
>> ok. I get it.
>>
>> I would like to understand some more of reverse-conditional branches
>> in case of float. For the target I am working on (AVR32), ?there is a
>> floating point unit which follows IEEE 754. The port is relatively
>> stable. We are now incrementally building support for these FPU
>> instructions (like fadd, fmul, fcmp).
>>
>> Now for the same test case with float data type, after expand pass, in
>> one of the passes (outof_cfglayout) the direct-conditional branches
>> are turned to reverse-conditional branches.
>>
>>
>> Direct-conditional branch
>>
>>> (jump_insn 9 8 34 3 gt.c:4 (set (pc)
>>> ? ? ? ? (if_then_else (gt:CC (cc0)
>>> ? ? ? ? ? ? ? ? (const_int 0 [0x0]))
>>> ? ? ? ? ? ? (label_ref 12)
>>> ? ? ? ? ? ? (pc))) -1 (nil))
>>
>> Reverse-conditional Branch
>>
>>> (jump_insn 9 8 34 3 gt.c:4 (set (pc)
>>> ? ? ? ? (if_then_else (gt:CC (cc0)
>>> ? ? ? ? ? ? ? ? (const_int 0 [0x0]))
>>> ? ? ? ? ? ? (pc))) -1 (nil))
>>> ? ? ? ? ? ? (label_ref 14)
>>
>> (Sorry that I don't have access to the installation right now, so I
>> just manually modified the reverse-conditional branch. The idea is to
>> illustrate that label_ref and pc are interchanged).
>>
>> The latter pattern is supposed to emit assembly which tests for the
>> reverse-condition. For instance if ?the former pattern emits assembly
>> instruction like "brgt <label>" then the latter pattern is supposed to
>> emit instruction like "brle <label>"
>
> That's the misunderstanding. ?The above should emit a brngt <label>
> (branch if !gt).
>

OK. We are using the same branch pattern for INT as well as all modes.
For int, generating "brle" should be fine I think where as float this
is wrong. So that leaves us to define a separate branch pattern for
floating mode.

It would be very interesting to know why a direct-conditional branch
is turned to reverse-conditional branch at all... I have been skimming
through jump.c and cfglayout.c for some clues.

Anitha


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]