[llvm-commits] [llvm] r163302 - in /llvm/trunk: lib/Transforms/Utils/SimplifyCFG.cpp test/Transforms/SimplifyCFG/switch_create.ll test/Transforms/SimplifyCFG/switch_to_lookup_table.ll

[Evan Cheng]

I think this is a reasonable approach. Can you verify that it handles all the cases? That is, disabling the simplifycfg optimization generates the same code as simplifycfg + converting table back to switches?

Evan

On Sep 11, 2012, at 10:01 AM, Hans Wennborg <hans at chromium.org> wrote:

> On Mon, Sep 10, 2012 at 7:19 PM, Evan Cheng <evan.cheng at apple.com> wrote:
>> The *right* longer term solution is to expose more target info to LLVM IR
>> passes. It's going to be more and more important especially with recent
>> interest in vectorization. I am fairly certain we'll start exposing some
>> target "instruction cost" (to start) in 2013.
>> 
>> That said, I think we will need a short term compromise. Hans, can you
>> experiment with moving this to codegenprep? I'd like to see what are the
>> interaction with other IR optimizations.
> 
> I've been looking into moving this to codegenprep today. One of the
> issues that came up is that if we move out of SimplifyCFG, we don't
> get the benefit from some of the clean-ups it does, e.g. removing
> unreachable blocks, merging blocks, etc. It seems that the codegen
> passes manage to clean this up pretty well, but the output on the IR
> level is not as good.
> 
> Another thing is that I couldn't find a way to run codegenprep via opt
> so that TargetLowerInfo is available. I guess this means I wouldn't be
> able to test my transformation via opt, but should use llc instead? Or
> I guess I could turn the logic around and do my transformation
> *unless* there is TLI available which says we shouldn't do it.
> 
> Talking to Duncan on IRC, he thinks we should not move this to
> CodeGenPrepare, but instead look into converting the table look-ups
> back into switches for those targets that need it, and that this would
> benefit other loads from constants as well. We could do this quite
> easily in CodeGenPrepare, I think. It would look something like the
> attached (work in progress) patch.
> 
> Please let me know what you think.
> 
> Thanks,
> Hans
> <load_to_switch.patch>