[PATCH] D35578: Add -fswitch-tables and -fno-switch-tables flags

[Chad Rosier via Phabricator via llvm-commits]

mcrosier added a comment.

In https://reviews.llvm.org/D35578#814817, @sgundapa wrote:

> > Wouldn't the fix be to make the backend deal with this, then? Either by putting the table with the function text, or or opting out of lookup tables? It seems that might be a better experience for the user.
>
> That is perfectly reasonable and in fact  i have committed a hexagon change recently to that effect . The llvm flag hexagon-emi-lookup-tables controls the generation of lookup table for hexagon.
>  The problem is, I don't want the users of the compiler to use a combination of front end and back end flags to get the desired result.


First, command-line flags (i.e., those predicated with -mllvm) were never designed to be customer facing.  They have no guarantee that they will persist and are generally undocumented.  They're designed to be used by those working on LLVM to simplify tuning/testing.  Any other use is likely a misuse.

> "-fno-jump-tables -mllvm -hexagon-emit-lookup-tables=false". This could be much neater with a "-fno-jump-tables -fno-lookup-tables" or better just "-fno-switch-tables"

I'm still very far from convinced adding new flags and proposing that users switch from using the long-standing -fno-jump-tables flag to the -fno-switch-tables flag is the right approach.  Are you going to convince the GCC community to do the same?

It sounds like to me you have some cases when you do want lookup tables and other cases that you don't.  What exactly is the determining factor here?  Moreover, why can't this determining factor be built into the compiler so the user doesn't even have to bother.  That would be a more ideal user experience.

As an alternative solution, why not just disable the transformation in SimplifyCFG when -fno-jump-tables is used?  The underlying issue seems to be the same (i.e., you want to avoid generating more relocations) and AFAICT that's what -fno-jump-tables is all about..  (Admittedly, I don't know the full history of -fno-jump-tables, so others might disagree with this suggestion.)


https://reviews.llvm.org/D35578