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.