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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
