RE: [sv-bc] FW: Manti 1345, 1711: unique if/case

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?

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.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.