sgundapa added a comment. I will try to address the concerns here:
> What exactly is the motivation? I'm trying to narrow down the justification > for adding yet more flags. (I just typed this message in https://reviews.llvm.org/D35579) For backends with "tightly coupled memory", in scenarios where the data is far away from text pays a good amount of penalty in terms of latency. Hexagon is one such backend. The tables (both lookup and jump) which are being generated are treated as globals with internal linkage and by default will be placed in read only data. Interestingly when programmers specify the command line flag "-fno-jump-tables", they assume there is no data that goes in to other sections. In case of llvm, the attribute "no-jump-tables" has no effect on simplifyCFG which generates the lookup table. This leads me to introduce "no-lookup-tables" > Either way, it sounds like "-fno-switch-tables" is just a synonym for the > (soon-to-be-)existing options "-fno-jump-tables -fno-lookup-tables" and > therefore doesn't need to exist as a separate option Ideally I want to rename fno-jump-tables to fno-switch-tables. > LLVM backends can opt out of these kinds of tables if they're not suitable > for the target, but why would a Clang user want to do it? Often TCM memory is small enough and this needs support for both cases(generate tables and do not generate tables) https://reviews.llvm.org/D35578 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
