Page MenuHomePhabricator

Driver: Replace switch cases with ifs.

Authored by ruiu on Feb 6 2015, 4:42 PM.



We used to do like this instead of putting all command line processing
code within one gigantic switch statement. It is converted to a switch
in r188958, which introduced InputGraph.

Making bunch of ifs to one switch statement with bunch of cases weren't
needed for InputGraph, so I don't know why that change was made in the
first place.

In this patch I roll that change back. Now all "break"s are removed,
and the nesting is one level shallow.

Diff Detail

Event Timeline

ruiu updated this revision to Diff 19518.Feb 6 2015, 4:42 PM
ruiu retitled this revision from to Driver: Replace switch cases with ifs..
ruiu updated this object.
ruiu edited the test plan for this revision. (Show Details)
ruiu added a reviewer: shankarke.
ruiu added a project: lld.
ruiu added a subscriber: Unknown Object (MLST).
shankar.easwaran added inline comments.

Is it directive ? If so spell error.


BumpPtrAllocator will be destructed as soon it is out of scope ?


Why do you need to allocate the string ?


If you lower case the argument value in the variable val, the code would become more readable.

ruiu added inline comments.Feb 6 2015, 6:44 PM

This spelling is correct. It's a section name.


I believe this is correct. This is not new code at least.


This is not new code. Basically everything is mechanical translation from the original.



Ok. LGTM with those changes that you are done with.

This revision is now accepted and ready to land.Feb 6 2015, 6:46 PM
ruiu added a comment.Feb 6 2015, 6:53 PM

The commit message of r188958 is very terse, it just says "add InputGraph
functionality", although it modified more than 1k lines of code. I'm
wondering why it was needed to convert ifs to cases at that moment. Do you

shankarke edited edge metadata.Feb 6 2015, 7:00 PM

a) would be easier to add more options, just add another case statement
b) easy to transition state from one option to another in case of positional options.
c) sometimes specifying the same argument multiple times is invalid, so becomes easier to check too.

ruiu added a comment.Feb 6 2015, 7:11 PM

Do you think they still stand?

(a) is a matter of taste, but well, if something can be written using if, I
wouldn't convert it to a switch. (b) is not a matter -- OptTable handles
optional arguments for you. For (c) we didn't do duplication check.

i dont think it matters for PECOFF/Core. Its just a style that I used and wanted to stay consistent.

ruiu added a comment.Feb 6 2015, 7:30 PM

I'm asking because I'm going to do the same thing for other dirvers for
consistency, so it doesn't stay here.

I really dont understand, Its a matter of style, every developer may choose to follow different styles. Nothing is written in the coding convention document about what style to choose over another.

ruiu added a comment.Feb 9 2015, 3:41 PM

That's what I wanted to ask you. We didn't have this gigantic switch and
lots of break's there but a series of small ifs. You did converted them as
a part of unrelated change (which is the large InputGraph patch) without
any explanation. Yes, the original code looks better to me, and I guess
that's at least part of the reason why the original code was written as it
was. I'm basically trying to restore the original code.

silvas added a subscriber: silvas.Feb 9 2015, 4:30 PM

This probably makes sense for consistency with clang, but FYI with current
libOption each of the "getLastArg" is linear in the command line length, so
the previous switch version was actually much more efficient.

This might be more problematic for LLD than for clang since linker command
lines can sometimes end up being much longer than compiler command lines.

The right fix of course is for libOption to cache or otherwise avoid
O(cmdline length) work per getLastArg.

  • Sean Silva
Eugene.Zelenko added a subscriber: Eugene.Zelenko.

Committed in r228646.