[PATCH] Constant folding around pre-increment loads and stores

Krzysztof Parzyszek kparzysz at codeaurora.org
Mon Feb 4 10:32:14 PST 2013


On 2/4/2013 12:04 PM, Hal Finkel wrote:
>
> Can you be more specific? Do you mean pre-inc formation in general, or just the associated constant folding? and why?

Sorry, should have been more specific.  Yes, I meant pre-increment in 
general (as well as post-increment).  The reason is that such compound 
instructions can obstruct subsequent analyses without really adding much 
benefit.  Post-increments (which I believe are expressed as "update" 
instructions) are cracked anyways (IIRC), so they are not equivalent 
from the point of view of group formation (again IIRC).  In a given 
situation it may be better to have the loads separated from the add, and 
it may not be clear at the time of instruction selection.

Details of PPC aside, having the code expressed via "fine grain" 
instructions would allow the optimizer to be more aggressive, especially 
on RISC architectures.  My vision, even for Hexagon, would be to have an 
"instruction combiner" that, after the higher-level machine 
optimizations are done, would generate complex instructions out of the 
"fine" ones.

In any case, changing the existing implementation to do things in a 
different order would be a major effort, so I'm not going to push for 
anything.  I just wanted to voice my opinion, in case it may be relevant 
in some future design considerations.

-Krzysztof


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation



More information about the llvm-commits mailing list