OK, I'll check in the previous patch
On Wed, Sep 8, 2010 at 10:02 AM, Jian-Xin Lai <laij...@gmail.com> wrote:
> You are right.
> We did some testing and found a lot of regressions caused by the new change.
> So we should still use the previous patch?
>
> 2010/9/7 Yiran Wang <yiran.w...@gmail.com>
>>
>> It cannot work. Complex lowering would lower complex-types C8 to V16C8 or
>> F8.
>> There can be too solutions
>> 1. C8 and V16C8 are complex types, while C8 is machine-independent-complex
>> types, which is lowered by complex lowering (to modify complex lowering a
>> bit.).
>> 2. V16C8 are defined as machine-implemented-complex-type, and we deal it
>> in the say way as "normal" complex type at some situation (which is
>> mentioned by Yong-Chong's patch). This solution seems weird a bit, but it
>> follows original design of complex lowering.
>> Best Regards,
>> yiran
>>
>> On Sun, Sep 5, 2010 at 9:47 PM, Jian-Xin Lai <laij...@gmail.com> wrote:
>>>
>>> Yes. Two examples:
>>> +#ifdef TARG_X8664
>>> if (!MTYPE_is_complex(ctype) && !(ctype == MTYPE_V16C8))
>>> +#else
>>> + if (!MTYPE_is_complex(ctype))
>>> +#endif
>>>
>>> We can change to
>>> if (!MTYPE_is_complex(ctype))
>>>
>>> +#ifdef TARG_X8664
>>> if (ltype == MTYPE_V16C8 || MTYPE_is_complex(ltype))
>>> +#else
>>> + if (MTYPE_is_complex(ltype))
>>> +#endif
>>>
>>> We can change to
>>> if (MTYPE_is_complex(ltype))
>>>
>>> 2010/9/5 Wu Yongchong <wuyongch...@gmail.com>
>>>>
>>>> These two lines are still inside the #ifdef TARG_X8664 in the original
>>>> code. Do you mean I move them out of the #ifdef condition?
>>>> By doing this , I'm not only get ride of the #ifdef TARG_X8664, but
>>>> also delete some #ifdef TARG_X8664 in the previous revision.
>>>>
>>>> 2010/9/5 Jian-Xin Lai <laij...@gmail.com>:
>>>> > Another issue (sorry for not pointing it out in the previous mail):
>>>> > MTYPE_V16C4/MTYPE_V16C8 should be also complex data type.
>>>> > I think we should change the mtype.cxx:
>>>> > 116 { MTYPE_V16C4, 128,128,128,16, 16,16, 0, 1, 0,
>>>> > "V16C4",MTYPE_CLASS_FLOAT|MTYPE_CLASS_VECTOR,16, MTYPE_V16C4 },
>>>> > 117 { MTYPE_V16C8, 128,128,128,16, 16,16, 0, 1, 0,
>>>> > "V16C8",MTYPE_CLASS_FLOAT|MTYPE_CLASS_VECTOR,16, MTYPE_V16C8 },
>>>> >
>>>> > into
>>>> > 116 { MTYPE_V16C4, 128,128,128,16, 16,16, 0, 1, 0,
>>>> > "V16C4",MTYPE_CLASS_COMPLEX_FLOAT|MTYPE_CLASS_VECTOR,16, MTYPE_V16C4
>>>> > },
>>>> > 117 { MTYPE_V16C8, 128,128,128,16, 16,16, 0, 1, 0,
>>>> > "V16C8",MTYPE_CLASS_COMPLEX_FLOAT|MTYPE_CLASS_VECTOR,16, MTYPE_V16C8
>>>> > },
>>>> >
>>>> > So that we can get rid of most of the #ifdef TARG_X8664 in the patch.
>>>> > But,
>>>> > since we change the mtypes.cxx, we need more testing on this change.
>>>> >
>>>> > 2010/9/4 Wu Yongchong <wuyongch...@gmail.com>
>>>> >>
>>>> >> sorry, the last email has no attachment, here is the new patch
>>>> >> 2010/9/5 Wu Yongchong <wuyongch...@gmail.com>:
>>>> >> > here is the new patch
>>>> >> > 2010/9/5 Wu Yongchong <wuyongch...@gmail.com>:
>>>> >> >> Hi
>>>> >> >> in ieee_module_support.c function _Ieee_get_underflow_mode_()
>>>> >> >> does
>>>> >> >> not support on IA64.
>>>> >> >> Indeed, I set tow much #ifdef in
>>>> >> >> osprey/libfi/mathlb/mathlb.gmakeinclude. There is just 1 file get
>>>> >> >> compile error.
>>>> >> >>
>>>> >> >> 2010/9/4 Jian-Xin Lai <laij...@gmail.com>:
>>>> >> >>> One comment:
>>>> >> >>> in osprey/libfi/mathlb/mathlb.gmakeinclude
>>>> >> >>> We can enable the module/c binding support/ieee/iso c/etc on
>>>> >> >>> IA-64.
>>>> >> >>> What's
>>>> >> >>> the problem if we compile these files on IA-64?
>>>> >> >>>
>>>> >> >>> 2010/9/2 Wu Yongchong <wuyongch...@gmail.com>
>>>> >> >>>>
>>>> >> >>>> Hi,
>>>> >> >>>> Can gatekeeper help review this patch.
>>>> >> >>>> Revision 3314 break the compiler in IA64 system, this patch
>>>> >> >>>> enclose
>>>> >> >>>> some of the change with #ifdef Macros .
>>>> >> >>>>
>>>> >> >>>> --
>>>> >> >>>> yongchong
>>>> >> >>>>
>>>> >> >>>>
>>>> >> >>>>
>>>> >> >>>>
>>>> >> >>>> ------------------------------------------------------------------------------
>>>> >> >>>> This SF.net Dev2Dev email is sponsored by:
>>>> >> >>>>
>>>> >> >>>> Show off your parallel programming skills.
>>>> >> >>>> Enter the Intel(R) Threading Challenge 2010.
>>>> >> >>>> http://p.sf.net/sfu/intel-thread-sfd
>>>> >> >>>> _______________________________________________
>>>> >> >>>> Open64-devel mailing list
>>>> >> >>>> Open64-devel@lists.sourceforge.net
>>>> >> >>>> https://lists.sourceforge.net/lists/listinfo/open64-devel
>>>> >> >>>>
>>>> >> >>>
>>>> >> >>>
>>>> >> >>>
>>>> >> >>> --
>>>> >> >>> Regards,
>>>> >> >>> Lai Jian-Xin
>>>> >> >>>
>>>> >> >>
>>>> >> >>
>>>> >> >>
>>>> >> >> --
>>>> >> >> yongchong
>>>> >> >>
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> > --
>>>> >> > yongchong
>>>> >> >
>>>> >>
>>>> >>
>>>> >>
>>>> >> --
>>>> >> yongchong
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > Regards,
>>>> > Lai Jian-Xin
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> yongchong
>>>
>>>
>>>
>>> --
>>> Regards,
>>> Lai Jian-Xin
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> This SF.net Dev2Dev email is sponsored by:
>>>
>>> Show off your parallel programming skills.
>>> Enter the Intel(R) Threading Challenge 2010.
>>> http://p.sf.net/sfu/intel-thread-sfd
>>> _______________________________________________
>>> Open64-devel mailing list
>>> Open64-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/open64-devel
>>>
>>
>
>
>
> --
> Regards,
> Lai Jian-Xin
>
--
yongchong
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel
