qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Consult] tilegx: About floating point instructions


From: Chen Gang
Subject: Re: [Qemu-devel] [Consult] tilegx: About floating point instructions
Date: Sun, 16 Aug 2015 09:41:02 +0800
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0

On 8/16/15 02:16, Chen Gang wrote:
> 
> On 8/15/15 23:47, Richard Henderson wrote:
>> On Aug 15, 2015 2:56 AM, Chen Gang <address@hidden>
>>> Oh, we are unlucky, after continue gcc testsuite, add/sub floating point 
>>> insns also can be mixed together! The related C code, -save-temps, and 
>>> objdump files are in attachments (is it gcc's issue? I guess not). 
>>>
>>> So, I guess, we have to 'crack' all floating point insns, precisely, or 
>>> we can not pass gcc testsuite. 
>>>
>>
>> If you go back to my first message to you on the subject, you'll find that 
>> my suggestion was to not split the operation at all, using move for pack1.  
>> Which would nicely handle any such interleaving.
>>
> 
> OK, thanks, but for float(uns)sisf2 and float(uns)sidf2, we can not only
> simply move.  :-(
> 
> But what you said is really quite valuable to me!! we can treat the flag
> as a caller saved context, then can let the caller can use callee freely
> (in fact, I guess, the real hardware treats it as caller context, too).
> 
>  - we have to define the flag format based on the existing format in the
>    related docs and tilegx.md (reserve 0-20 and 25-31 bits).
> 
>  - We can only use 21-24 for mark addsub, mul, or typecast result. If
>    21-24 bits are all zero, it means typecast result. For fsingle: 32-63
>    bits is the input integer; for fdouble: srca is the input integer.
> 
>  - For addsub and mul result, we use 32-63 bits for an index of resource
>    handler (like 'fd' returned by open). fsingle_addsub2, fsingle_mul1,
>    fdouble_mul_flags, fdouble_addsub allocate resource, and pack1 free.
> 
> But if caller "make mistakes", our implementation can not avoid related
> resource leak (but the real hardware can, it also lets caller save all
> related resources; when it needs them, it can let caller pass them to).
> 

If we assume that the optimization for the floating point insns can not
cross the basic blocks (I guess so), we can reset all related resources
when start a basic block.


Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed



reply via email to

[Prev in Thread] Current Thread [Next in Thread]