[PATCH] ARM: Form paired load after stack coloring.

Quentin Colombet qcolombet at apple.com
Tue Jun 11 22:59:18 PDT 2013


Thanks Andy.

For some reasons, I missed your reply (until then), sorry about that.

I will wait for Evan to comment on this to see if we miss something obvious, just in case.

Thanks again for the insightful comments. I appreciate.

Cheers,

-Quentin

On Jun 10, 2013, at 6:36 PM, Andrew Trick <atrick at apple.com> wrote:

> 
> On Jun 6, 2013, at 5:00 PM, Quentin Colombet <qcolombet at apple.com> wrote:
> 
>> Hi,
>> 
>> ** Context **
>> Recently lifetime markers have been generated by clang in the IR to be able to take advantage of the stack coloring pass.
>> When these markers are set, the stack coloring pass changes, among other things, the value (setValue) attached to MachineMemoryOperand. In particular, this optimization is setting the value to 0 (<unknown>) when it cannot determine that the value does not alias with a merged alloca (StackColoring.cpp:540).
>> 
>> In the ARM backend, the load/store optimizer checks the presence of this value to decide whether it should form paired load or paired store.
>> 
>> Therefore, the stack coloring pass disables the capabilities of the ARM backend to form paired load or paired store before register allocation.
>> <rdar://problem/13978317>
>> 
>> ** Proposed Solution **
>> The attached patch removes the dependence of the ARM backend on the value (in fact, this was a false dependency, at least from what I understood).
>> In particular, it does not change the stack coloring pass, as setting the value to 0 seems the right thing to do for this analysis.
>> 
>> ** Test Cases **
>> The patch adds one test case of a paired load formed when lifetime marker are present (prior to this patch, the paired load is not formed for this test case).
>> The patch also modifies test/CodeGen/ARM/2012-10-04-AAPCS-byval-align8.ll. Indeed, because of the patch, in that test, we are able to form a paired load before register allocation. Because of a bad interaction with the coalescer, the register allocator is not able to set a proper pair for the paired load. This is causing the pair loaded to be break apart after register allocation.
>> Prior to this patch, the pair loaded was caught after register allocation, because both copies were coalesced. Anyway, the register allocator has not clue it may form a paired load when coalescing those.
>> If the patch is accepted, I will file an enhancement request against the register allocator.
>> 
>> ** Action Required **
>> - For Stack coloring pass expert: Confirm that the pass cannot preserve the value of the MachineMemoryOperand. I think the dependence of the ARM back on that is artificial but if we can preserve some information, why not!
> 
> I agree with Nadav that we cannot preserve the IR value. I would only add that we really want to preserve MachineMemOperands in this case, but it would require reimplementing stack coloring in IR.
> 
>> - For ARM backend expert: Confirm that the value is not required. Or put differently, what was the purpose checking if  a value was set?
> 
> AFAICT, the value is not currently required. It will be required when we decide to use AliasAnalysis in the LoadStoreOptimizer.
> 
> Essentially, if we ever want to rely on AliasAnalysis after StackColoring, we need to reimplement StackColoring at IR level. For now your patch LGTM.
> 
> -Andy
> 
>> Thanks for the review,
>> 
>> -Quentin
>> <Mail Attachment>
>> _______________________________________________
>> 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/20130611/9089697b/attachment.html>


More information about the llvm-commits mailing list