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

Sumanth Gundapaneni via Phabricator via llvm-commits llvm-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 llvm-commits mailing list