[PATCH] D35578: Add -fswitch-tables and -fno-switch-tables flags
Sumanth Gundapaneni via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Wed Jul 19 15:50:12 PDT 2017
sgundapa added a comment.
> 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.
Here is a use case : For the code that stays in TCM, the customer doesn't want the data that the code refers to be outside of TCM. As kparzysz mentioned, the loads cause a huge latency and is not intended. Disabling table generation is the right thing to do here. For code that stays in regular memory, generating tables is far more efficient than a bunch of if-elses.
> 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.)
Jump tables are not supported by all targets but lookup tables are. Jump tables need indirect addressing mode where as a lookup table is just an array of values.
This is from "man gcc"
Do not use jump tables for switch statements even where it would be more efficient than other code generation strategies. This option is of use in conjunction with -fpic or -fPIC for building code that forms part of a
dynamic linker and cannot reference the address of a jump table. On some targets, jump tables do not require a GOT and this option is not needed.
This will throw some background on why this option was introduced.
More information about the cfe-commits