en, I will take a look to see whether there are chances to remove them out.
Thanks
Gang
On Wed, Aug 3, 2011 at 9:12 PM, Sun Chan <sun.c...@gmail.com> wrote:
> right, I forgot. I am fine with the change.
> One other thing, how would Is_Target_Orochi and OP_sse5 be dealt with
> and thus eliminate yet another #ifdef?
> sun
>
> On Wed, Aug 3, 2011 at 8:58 PM, Gang Yu <yugang...@gmail.com> wrote:
> > According to Mike, it is only defined in
> > osprey/common/com/x8664/config_targ.cxx
> > Gang
> >
> >
> > On Wed, Aug 3, 2011 at 8:33 PM, Sun Chan <sun.c...@gmail.com> wrote:
> >>
> >> where is your Is_Target_SSE41() defined, say, for SL?
> >> Sun
> >>
> >> On Wed, Aug 3, 2011 at 8:24 PM, Gang Yu <yugang...@gmail.com> wrote:
> >> > Sun:
> >> >
> >> > According to Mike's suggestion, I have a revised patch for this
> >> > broken
> >> > issue.
> >> >
> >> > Since there are no lnoconfig_stacks in use, putting the
> >> > LNO_Iter_threshold to target specific config_targ.cxx is safe. with
> only
> >> > the
> >> > side effect of setting the LNO_iter_threshold multiple times. Since
> each
> >> > backend component calls the Configure_Target once.
> >> >
> >> > Another issue is that when I test the patch on an xeon E5620
> >> > workstation,
> >> > the compiler reports the machine does not support SSE4.1 which is
> >> > obviously
> >> > supported.
> >> >
> >> > Please help a review.
> >> >
> >> > Gang
> >> >
> >> >
> >> > On Fri, Jul 22, 2011 at 6:37 AM, Sun Chan <sun.c...@gmail.com> wrote:
> >> >>
> >> >> Since this is an AMD change, can the original developer change it the
> >> >> way Mike suggested?
> >> >> Thx!
> >> >> Sun
> >> >>
> >> >> 2011/7/21 Mike Murphy <mmur...@nvidia.com>:
> >> >> > I took a quick look at the original issue in config_lno, and it
> seems
> >> >> > to
> >> >> > me that the simplest solution would be to reset the iter_threshold
> >> >> > value in
> >> >> > x8664/config_targ.cxx (e.g. we set some target-specific defaults in
> >> >> > Preconfigure_Target). That way the change is only in the x86
> branch.
> >> >> >
> >> >> > -----Original Message-----
> >> >> > From: Sun Chan [mailto:sun.c...@gmail.com]
> >> >> > Sent: Thursday, July 21, 2011 7:39 AM
> >> >> > To: C. Bergström
> >> >> > Cc: open64-devel
> >> >> > Subject: Re: [Open64-devel] Please help review a build broken fix
> for
> >> >> > non-x86 targets [CG][LNO]
> >> >> >
> >> >> > just to be clear, what i suggested as a better solution is for any
> >> >> > implementation of target specific stuff consists of
> >> >> > at least two implementations, one generic and one specialize. This
> >> >> > way, it will not break any build, while give the specific target
> the
> >> >> > implementation the developer really wants. The actual
> implementation
> >> >> > could be templates, or weak/strong symbols
> >> >> > Naturally, any better solution is welcome. Let's put to rest any
> >> >> > argument on Is_target_xxx or ifdef.
> >> >> > Sun
> >> >> >
> >> >> > 2011/7/21 Sun Chan <sun.c...@gmail.com>:
> >> >> >> I had suggested two better solutions before. The point is,
> >> >> >> originally,
> >> >> >> before STL like style is popular, Is-Target_xxx is used to isolate
> >> >> >> target dependent stuff. Short of a better soln, and having done
> >> >> >> retarget and rehost for a very long life time (and still doing it
> >> >> >> now.
> >> >> >> )
> >> >> >> I would welcome better soln's, but definitely no #ifdefs or the
> >> >> >> proliferation of that
> >> >> >> Sun
> >> >> >>
> >> >> >> 2011/7/21 "C. Bergström" <cbergst...@pathscale.com>:
> >> >> >>> On 07/21/11 11:38 AM, shuxin yang wrote:
> >> >> >>>> Is_Target_xyz() is worse than #ifdef in the sense:
> >> >> >>>> - it dosen't improve the retargetability a bit,
> >> >> >>>> - replacing #ifdef with is_target_xyz() tends to give new
> >> >> >>>> developers false impression that open64 has high degree of
> >> >> >>>> retargetability, which is absolutely *NOT*
> >> >> >>>>
> >> >> >>>> Is_Target_syz() is illusion, not solution...
> >> >> >>> Speaking from the perspective of someone who has been involved
> with
> >> >> >>> 1) Multiple real world retargets
> >> >> >>> 2) Maintaining multiple targets and branches
> >> >> >>> 3) Porting and maintaining code across several OS
> >> >> >>>
> >> >> >>> #if == hell
> >> >> >>> ------------------
> >> >> >>> It doesn't immediately solve the problem, but what if all the
> >> >> >>> target
> >> >> >>> specific functions were in a single file or directory? Slow and
> >> >> >>> steady
> >> >> >>> progress will eventually win if there's a plan.
> >> >> >>>
> >> >> >>> I can't speak for the best solution in this case, but generally
> >> >> >>> thought
> >> >> >>> to chime in..
> >> >> >>>
> >> >> >>>
> >> >> >>>
> >> >> >>>
> >> >> >>>
> >> >> >>>
> ------------------------------------------------------------------------------
> >> >> >>> 5 Ways to Improve & Secure Unified Communications
> >> >> >>> Unified Communications promises greater efficiencies for
> business.
> >> >> >>> UC
> >> >> >>> can
> >> >> >>> improve internal communications as well as offer faster, more
> >> >> >>> efficient ways
> >> >> >>> to interact with customers and streamline customer service. Learn
> >> >> >>> more!
> >> >> >>> http://www.accelacomm.com/jaw/sfnl/114/51426253/
> >> >> >>> _______________________________________________
> >> >> >>> Open64-devel mailing list
> >> >> >>> Open64-devel@lists.sourceforge.net
> >> >> >>> https://lists.sourceforge.net/lists/listinfo/open64-devel
> >> >> >>>
> >> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> ------------------------------------------------------------------------------
> >> >> > 5 Ways to Improve & Secure Unified Communications
> >> >> > Unified Communications promises greater efficiencies for business.
> UC
> >> >> > can
> >> >> > improve internal communications as well as offer faster, more
> >> >> > efficient
> >> >> > ways
> >> >> > to interact with customers and streamline customer service. Learn
> >> >> > more!
> >> >> > http://www.accelacomm.com/jaw/sfnl/114/51426253/
> >> >> > _______________________________________________
> >> >> > Open64-devel mailing list
> >> >> > Open64-devel@lists.sourceforge.net
> >> >> > https://lists.sourceforge.net/lists/listinfo/open64-devel
> >> >> >
> >> >> >
> >> >> >
> -----------------------------------------------------------------------------------
> >> >> > This email message is for the sole use of the intended recipient(s)
> >> >> > and
> >> >> > may contain
> >> >> > confidential information. Any unauthorized review, use, disclosure
> >> >> > or
> >> >> > distribution
> >> >> > is prohibited. If you are not the intended recipient, please
> contact
> >> >> > the sender by
> >> >> > reply email and destroy all copies of the original message.
> >> >> >
> >> >> >
> >> >> >
> -----------------------------------------------------------------------------------
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >>
> ------------------------------------------------------------------------------
> >> >> 5 Ways to Improve & Secure Unified Communications
> >> >> Unified Communications promises greater efficiencies for business. UC
> >> >> can
> >> >> improve internal communications as well as offer faster, more
> efficient
> >> >> ways
> >> >> to interact with customers and streamline customer service. Learn
> more!
> >> >> http://www.accelacomm.com/jaw/sfnl/114/51426253/
> >> >> _______________________________________________
> >> >> Open64-devel mailing list
> >> >> Open64-devel@lists.sourceforge.net
> >> >> https://lists.sourceforge.net/lists/listinfo/open64-devel
> >> >
> >> >
> >
> >
>
------------------------------------------------------------------------------
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts.
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel
