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.