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
------------------------------------------------------------------------------
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
