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