Gordon, how much performance are we talking about? Again this seems like a very rare coding condition and the benefits of getting the implementations on the same page seem a lot more important to me than a small performance improvement. -Tom >-----Original Message----- >From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On >Behalf Of Gordon Vreugdenhil >Sent: Monday, November 19, 2007 9:11 AM >To: Bresticker, Shalom >Cc: sv-bc@server.eda.org >Subject: Re: [sv-bc] FW: Manti 1345, 1711: unique if/case > > > >Bresticker, Shalom wrote: >> But you also seemed to say that you do not object to restricting >> optimizations. >> >> And I will ask again, is optimization of a uniqueness violation really >> important? > >It can be. I'd rather not get into details, but choices in this >area can impact simulator performance even for evaluation >sequences that don't go through the failure branch. > >Gord. > > >> >> Thanks, >> Shalom >> >>> -----Original Message----- >>> From: owner-sv-bc@server.eda.org >>> [mailto:owner-sv-bc@server.eda.org] On Behalf Of Gordon Vreugdenhil >>> Sent: Monday, November 19, 2007 6:58 PM >>> To: Bresticker, Shalom >>> Cc: sv-bc@server.eda.org >>> Subject: Re: [sv-bc] FW: Manti 1345, 1711: unique if/case >>> >>> >>> >>> Bresticker, Shalom wrote: >>>> Sorry, now I am confused. >>>> >>>> Essentially what was proposed by Steven and Tom (and I do >>> not object) >>>> is to specify an order allowing only short-circuiting. Then >>> there is >>>> no special consideration of side-effects, and whatever happens >>>> happens, according to the rules. >>> >>> The impact of the current suggestions is that for the example >>> that I originally suggested the optimization I want is illegal. >>> >>> unique case (expr) >>> 1 : ... /* action 1 */ >>> i++ : ... >>> 1 : ... /* action 2 */ >>> >>> Given the current suggestion, one MUST evaluate "i++" if you >>> are reporting a unique violation. I do not want to require >>> that evaluation. >>> >>> Gord. >>> >>> >>> > Is it a problem to say that a tool does not have >>>> to check whether there are side-effects, but caveat emptor >>> if you use >>>> them? (Or in other words, you deserve whatever you get.) I >>> don't see >>>> what your objection is anymore. >>>> >>>> Regards, >>>> Shalom >>>> >>>>> -----Original Message----- >>>>> From: owner-sv-bc@server.eda.org >>>>> [mailto:owner-sv-bc@server.eda.org] On Behalf Of Gordon Vreugdenhil >>>>> Sent: Monday, November 19, 2007 6:36 PM >>>>> To: Bresticker, Shalom >>>>> Cc: sv-bc@server.eda.org >>>>> Subject: Re: [sv-bc] FW: Manti 1345, 1711: unique if/case >>>>> >>>>> >>>>> >>>>> Bresticker, Shalom wrote: >>>>>> Gord, >>>>>> >>>>>> Thanks. >>>>>> >>>>>> Again I will ask why the LRM has to make an effort to >>>>> support such a >>>>>> unique case (not a pun). The uniqueness violation aside, >>> no one has >>>>>> yet provided a justification for side-effects in case_item >>>>> expressions >>>>>> in a unique case. >>>>> Oh, I'm certainly fine with disallowing side effects in >>> unique case >>>>> completely. If we want to go that route, the whole issue is moot. >>>>> >>>>>> I also suggest that statically determinable uniqueness violations >>>>>> indicate a problem and therefore optimizations don't >>> interest me in >>>>>> such situations anyway. >>>>> Someone could easily have duplicates due to edge case >>>>> parameterization, etc. that is never actually reachable in a >>>>> particular configuration of the circuit. >>>>> >>>>> > Plus those should be rare situations and >>>>>> not worth investing in their optimization. And if >>> predictability is >>>>>> some important, then would it not be more important than >>>>> optimization? >>>>> >>>>> Yes, which is why I'm willing to give up optimizations in >>> any cases >>>>> at all. The current suggestions already restrict previously valid >>>>> optimizations. >>>>> >>>>> Gord. >>>>> >>>>> >>>>> >>>>>> Regards, >>>>>> Shalom >>>>>> >>>>>>> Consider the following: >>>>>>> >>>>>>> unique case (expr) >>>>>>> 1 : ... /* action 1 */ >>>>>>> i++ : ... >>>>>>> 1 : ... /* action 2 */ >>>>>>> >>>>>>> I may want to optimize the statically determinable >>>>> non-unique cases >>>>>>> and not have to walk through things. So effectively I may want >>>>>>> something that looks like: >>>>>>> case (expr) >>>>>>> 1 : /* warn */ /* action 1 */ >>>>>>> i++ : ... >>>>>>> >>>>>>> I don't think that would be valid in the approaches that >>>>> you've been >>>>>>> discussing and I would object to making such >>> optimizations illegal. >>>>>>> I do agree that requiring a top-down ordering could be >>>>> required but >>>>>>> only until encountering a case that warns. So once you issue a >>>>>>> warning, no further evaluation is required and whether >>>>> evaluation of >>>>>>> case items which are between the first match and the match which >>>>>>> conceptually causes the warning is implementation defined. >>>>>>> >>>>>>> I think that gives us a reasonable approach -- if you have a >>>>>>> well-formed unique case, then you get top-down predictability. >>>>>>> Only when you have an ill-formed case, do you lose some >>>>>>> predictability. >>>>>>> While I agree with Steven that I don't want to penalize *all* >>>>>>> side-effects, I don't mind penalizing an ill-formed unique >>>>> case with >>>>>>> side-effects. >>> --------------------------------------------------------------------- >>>>>> Intel Israel (74) Limited >>>>>> >>>>>> This e-mail and any attachments may contain confidential >>>>> material for >>>>>> the sole use of the intended recipient(s). Any review or >>>>> distribution >>>>>> by others is strictly prohibited. If you are not the intended >>>>>> recipient, please contact the sender and delete all copies. >>>>> -- >>>>> >>> -------------------------------------------------------------------- >>>>> Gordon Vreugdenhil 503-685-0808 >>>>> Model Technology (Mentor Graphics) gordonv@model.com >>>>> >>>>> >>>>> -- >>>>> This message has been scanned for viruses and dangerous content by >>>>> MailScanner, and is believed to be clean. >>>>> >>> --------------------------------------------------------------------- >>>> Intel Israel (74) Limited >>>> >>>> This e-mail and any attachments may contain confidential >>> material for >>>> the sole use of the intended recipient(s). Any review or >>> distribution >>>> by others is strictly prohibited. If you are not the intended >>>> recipient, please contact the sender and delete all copies. >>> -- >>> -------------------------------------------------------------------- >>> Gordon Vreugdenhil 503-685-0808 >>> Model Technology (Mentor Graphics) gordonv@model.com >>> >>> >>> -- >>> This message has been scanned for viruses and >>> dangerous content by MailScanner, and is >>> believed to be clean. >>> >> --------------------------------------------------------------------- >> Intel Israel (74) Limited >> >> This e-mail and any attachments may contain confidential material for >> the sole use of the intended recipient(s). Any review or distribution >> by others is strictly prohibited. If you are not the intended >> recipient, please contact the sender and delete all copies. > >-- >-------------------------------------------------------------------- >Gordon Vreugdenhil 503-685-0808 >Model Technology (Mentor Graphics) gordonv@model.com > > >-- >This message has been scanned for viruses and >dangerous content by MailScanner, and is >believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Mon Nov 19 09:23:12 2007
This archive was generated by hypermail 2.1.8 : Mon Nov 19 2007 - 09:23:40 PST