[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"
-fno-jump-tables
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.
https://reviews.llvm.org/D35578
More information about the cfe-commits
mailing list