[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