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
Sanjiv Gupta wrote:> 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 >Sow we can write: case ( (switch_on "O0") [(append_cmd "-blah0"), (break)], (switch_on "O1")[(append_cmd "-blah1"), (break)], (switch_on "O2")[(append_cmd "-blah2"), (break)], (default) (append_cmd "-blah2")) This would require generation of an unique label after each case construct, and a goto uniquelabel; in each if ( ) {...} The other way is: if (first_test) { .... stop_case = true; } if (!stop_case && second_test) { ... stop_case = true; } if (!stop_case && third_test) { ... } else { // default case ... } stop_case = false; Also, it would be nice to have some "general predicates" to do some cleaning up of the command line. For example: if an user specifies all -O0, -O1, -O2 on the command line, one would be able to choose only the first or last, or give an error. option_validator ("O0", "O1", "O2"), (choose_first) OR option_validator ("O0", "O1", "O2"), (choose_last) OR option_validator ("O0", "O1", "O2"), (error "Only one of -O0, -O1, or -O2 are allowed).> _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
Mikhail Glushenkov
2009-Sep-10 12:25 UTC
[LLVMdev] Fwd: tblgen bug in handling case , switch_on
Hi, On Thu, Sep 10, 2009 at 7:26 AM, Sanjiv Gupta <sanjiv.gupta at microchip.com> wrote:> >> Another way would be to include a "break" command, to take you after the >> default label.Yes, this can be useful. I think we should add both 'break' and a 'match' form, and make 'match' the only one allowed in the cmd_line property. This will make the semantics of 'case' less ambiguous.> Also, it would be nice to have some "general predicates" to do some cleaning > up of the command line. > For example: if an user specifies all -O0, -O1, -O2 on the command line, one > would be able to choose only the first or last, or give an error. > > option_validator ("O0", "O1", "O2"), (choose_first) > OR > option_validator ("O0", "O1", "O2"), (choose_last) > OR > option_validator ("O0", "O1", "O2"), (error "Only one of -O0, -O1, or -O2 > are allowed).Good idea. I propose adding something along these lines: def Preprocess : OptionPreprocessor <[ (squash ["O1", "O2", "O3"], "O3"), (squash ["O1", "O2"], "O2"), (conflict (and (switch_on "E"), (switch_on "S"))), (warning (and (switch_on "E"), (switch_on "S")), "-E conflicts with -S") ]>; The preprocessing code will run once in the beginning. -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments
Mikhail Glushenkov wrote:> Hi, > > On Thu, Sep 10, 2009 at 8:01 PM, Sanjiv Gupta > <sanjiv.gupta at microchip.com> wrote: > >> Why do we need both 'conflict' and 'warning' ? >> > > 'warning' just prints a warning, 'conflict' is a fatal error. > > A better example would be something like: > > (warning (and (switch_on "O1"), (switch_on "O2")) "-O1 has no effect.") > > >Looks good. One more quick query. How to extract libname from "-l std" from the driver and pass it as "std.lib" to the linker tool? I know that unpack_values will give me "std", but an (append_cmd ".lib") with that will insert a space. Anything like append_cmd_nospace ? or any other way? - Sanjiv - Sanjiv
Mikhail Glushenkov
2009-Sep-11 12:10 UTC
[LLVMdev] tblgen bug in handling case , switch_on
Hi, On Fri, Sep 11, 2009 at 11:46 AM, Sanjiv Gupta <sanjiv.gupta at microchip.com> wrote:> > Looks good. > One more quick query. > How to extract libname from "-l std" from the driver and pass it as > "std.lib" to the linker tool? > I know that unpack_values will give me "std", but an (append_cmd ".lib") > with that will insert a space.This won't work since actions are not composable (alas).> Anything like append_cmd_nospace ? or any other way?I'm afraid there is no way to do this right now. One way to support this is to extend the hook mechanism to work with actions: (case (not_empty "-l"), (append_cmd "$CALL(AppendLibSuffix)")) -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments