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