llvm dev - Sep 2009 - [LLVMdev] tblgen bug in handling case , switch_on

Hi Sanjiv,

On Sun, Sep 6, 2009 at 8:07 PM, Mikhail
Glushenkov<the.dead.shall.rise at gmail.com>
wrote:
> [...]
[Sorry, the formatting was a bit off]
> The following snippet gives the expected behaviour (not tested, but
> you should get the idea):
(case
    (switch_on "O0"),
        (append_cmd "-disable-opt"),

    (or (and (switch_on "O1")
             (not (switch_on "O0"))),
        (not (switch_on "O0"))),
    (append_cmd "-constmerge -globaldce -globalopt -ipsccp
-jump-threading -simplifycfg -gvn -scalarrepl"),

    (or (and (switch_on "O2"),
             (not (switch_on "O0"))),
        (not (switch_on "O0"))),
    (append_cmd "-instcombine"))

> -O2 is the default, but -O0 overrides both -O2 and -O1; -O2 overrides -O1.

-- 
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Mikhail Glushenkov wrote:
> Hi Sanjiv,
>
> On Sun, Sep 6, 2009 at 8:13 PM, Mikhail
> Glushenkov<the.dead.shall.rise at gmail.com> wrote:
>   
>> Hi Sanjiv,
>>
>> On Sun, Sep 6, 2009 at 8:07 PM, Mikhail
>> Glushenkov<the.dead.shall.rise at gmail.com> wrote:
>>     
>>> [...]
>>>       
>> [Sorry, the formatting was a bit off]
>>
>>     
>>> The following snippet gives the expected behaviour (not tested, but
>>> you should get the idea):
>>>       
>
> BTW, your mail has got me thinking about the semantics of 'case',
> which is currently somewhat ambiguous (since it depends on context).
> Probably 'case' should be modified to always mean 'if ... else
if ...
> else if ... [...] else ...' 
IMO, we shouldn't think in terms of what code the user wants to 
generate; The syntax should rather specify what can you do with it. What 
code we generate  for that syntax is rather immaterial as long as it works.
Having said that, a "tblgen case ..... switch_on" is more like a
"C
switch....case" for me, and a if ... elseif...elseif...else is a valid 
way to handle it.
Now if we allow nesting, that should work as well.
> and the 'if (...) ... if (...) ... if
> (...) ... [...]' form should be called something like 'match'.
That
> would be backwards-incompatible, though.
>
> What do you think?
>   
Again, if an user wants to check for multiple conditions to be true 
before taking some action , we can devise a new construct for doing that.
A   match (this)...and ...match(this) ...and match(this)...    makes 
sense to me.

- Sanjiv

Mikhail Glushenkov wrote:
> Hi Sanjiv,
>
> On Sun, Sep 6, 2009 at 8:13 PM, Mikhail
> Glushenkov<the.dead.shall.rise at gmail.com> wrote:
>   
>> Hi Sanjiv,
>>
>> On Sun, Sep 6, 2009 at 8:07 PM, Mikhail
>> Glushenkov<the.dead.shall.rise at gmail.com> wrote:
>>     
>>> [...]
>>>       
>> [Sorry, the formatting was a bit off]
>>
>>     
>>> The following snippet gives the expected behaviour (not tested, but
>>> you should get the idea):
>>>       
>
> BTW, your mail has got me thinking about the semantics of 'case',
> which is currently somewhat ambiguous (since it depends on context).
> Probably 'case' should be modified to always mean 'if ... else
if ...
> else if ... [...] else ...' and the 'if (...) ... if (...) ... if
> (...) ... [...]' form should be called something like 'match'.
That
> would be backwards-incompatible, though.
>
> What do you think?
>
>   
Another way would be to include a "break" command, to take you after
the
default label.
- Sanjiv