[llvm-commits] [llvm] r107114 - /llvm/trunk/lib/Target/ARM/ARMLoadStoreOptimizer.cpp

[Evan Cheng]

I've looked into this. The main issue is when the register allocator folded reloads from fixed slots the loads ended up with alignment 1. That's because by default all fixed slots have alignment of 1. This is overly conservative. DAG combiner will infer the correct alignments from stack pointer alignments and frame offset. But at register allocation time we are simply taking the frame object's alignments.

I think the right fix is to make sure the fixed objects have the inferred alignments when they are created. Does anyone see a problem with that?

Evan

On Jun 29, 2010, at 6:03 PM, Evan Cheng wrote:

> 
> On Jun 29, 2010, at 1:39 PM, Jakob Stoklund Olesen wrote:
> 
>> 
>> On Jun 28, 2010, at 10:46 PM, Evan Cheng wrote:
>> 
>>> 
>>> On Jun 28, 2010, at 10:09 PM, Jakob Stoklund Olesen wrote:
>>> 
>>>> 
>>>> On Jun 28, 2010, at 10:00 PM, Evan Cheng wrote:
>>>> 
>>>>> 
>>>>> On Jun 28, 2010, at 6:13 PM, Jakob Stoklund Olesen wrote:
>>>>> 
>>>>>> Author: stoklund
>>>>>> Date: Mon Jun 28 20:13:07 2010
>>>>>> New Revision: 107114
>>>>>> 
>>>>>> URL: http://llvm.org/viewvc/llvm-project?rev=107114&view=rev
>>>>>> Log:
>>>>>> When no memoperands are present, assume unaligned, volatile.
>>>>> 
>>>>> Have you checked if this disabled a lot of potential optimizations? I am afraid assuming volatileness is overly conservative.
>>>> 
>>>> I haven't checked anything but running unit tests.
>>>> 
>>>> We need both non-volatile and 4-byte alignment to safely combine loads and stores. If memoperands are missing, I don't see any alternative. How else can we guarantee the optimization is valid?
>>>> 
>>>> If this causes missed optimizations, we should ensure that memory operands are present.
>>> 
>>> I agree. I am just wondering if that's indeed the case. Can you add a llc beta check to look for differences in # of load / store multiple optimizations?
>> 
>> I ran an assembly diff across the entire nightly test suite.
>> 
>> We lost 117 of 56783 ldms and 40 of 47702 stms.
> 
> Thanks. Can you file a bug about this? We should take a look.
> 
> Evan
> 
> _______________________________________________
> 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/20100702/6f8ebc4a/attachment.html>