[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]

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.

Thanks,

Evan

On Sep 10, 2012, at 9:09 AM, Owen Anderson <resistor at mac.com> wrote:

> 
> On Sep 10, 2012, at 12:58 AM, Hans Wennborg <hans at chromium.org> wrote:
> 
>> I'm not familiar with GPUs or deeply embedded systems. What are the
>> problems that my transformation is creating for them?
> 
> My qualm, which I suspect is the same on GPUs and MCUs, is that this kind of transform assumes a CPU-like very of the target's memory map, i.e. we're free to create new global allocations as we wish.  This is fine on your typical CPU, but not on a device whose memory layout is much more constrained.  On a GPU, the lookup table will either have to go in VRAM (very slow) or take up space in local memory (very precious), neither of which the programmer likely intended.  On an MCU, you're taking up valuable Flash or EEPROM space, and also potentially surprising the programmer is they're trying to take fine-grained control of their data and code layout.
> 
> I actually really like the transform in principle, I just think there needs to be a mechanism for targets to opt out of it without disabling SimplifyCFG entirely.
> 
> --Owen
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120910/ee2cf067/attachment.html>