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

[Hal Finkel]

----- Original Message -----
> From: "Krzysztof Parzyszek" <kparzysz at codeaurora.org>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: llvm-commits at cs.uiuc.edu
> Sent: Monday, February 4, 2013 12:32:14 PM
> Subject: Re: [PATCH] Constant folding around pre-increment loads and stores
> 
> 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.

Understood.

Regarding the PPC-specific comments: This depends on the target. For embedded cores, using the 'with update' forms are often free (not microcoded), and save cycles relative to the access along with an explicit add (this is certainly true on the A2, for example). For ooo cores, I think we'd eventually like to disable pre-inc formation unless we're optimizing for size.

> 
> 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.

Sounds good. PPC (the embedded cores), could certainly also benefit.

> 
> 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.

Sounds good to me.

Thanks again,
Hal

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