[llvm-commits] [llvm] r142530 - in /llvm/trunk: lib/Target/ARM/ARMISelLowering.cpp test/CodeGen/ARM/2011-10-18-DisableMovtSize.ll

[Evan Cheng]

On Oct 26, 2011, at 11:22 AM, Chris Lattner wrote:

> 
> On Oct 26, 2011, at 9:50 AM, Owen Anderson wrote:
> 
>> 
>> On Oct 26, 2011, at 12:37 AM, James Molloy wrote:
>> 
>>> I also heavily dislike the Darwin-specific stuff in the backend and the
>>> whole idea of "We don't want to do this for Darwin" - if something is a
>>> negative tradeoff, have an appropriate target-independent knob that can be
>>> turned to a different position for Darwin.
>> 
>> +1
>> 
>> I think the real issue here is that we don't have a way to distinguish -Os vs. -Oz at the IR level.  Perhaps we need a new function attribute to distinguish the two, though I don't know a good name for it offhand.  Then "We don't want this for Darwin" just becomes a policy decision in the driver.
> 
> I think we just want another attribute, just like OptimizeForSize but the Oz variant.  Maybe OptimizeForSizeHarder ;-)

Chris, you should go into marketing. :-)

Also note, there are cases where we should use loads in place of movw / movt even without -Oz. More specifically, in cases where we can combine multiple constantpool entries into one. We can then issue ldrd / ldm etc. for load multiple constantpool entries with a single instruction. However, there are several dependencies for this optimization.

1. LLVM needs to be able to model multi-literal constantpool entries (shouldn't be too hard)
2. We need to be able to model register sequences
3. Register allocator needs to be able rematerialize loads from individual entries.
4. The constantpool island pass should be able to handle these combined constantpool entries.
5. Test various ARM variants to understand what scenarios are actual wins.

Evan


> 
> -Chris
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits