[llvm] r207301 - [X86] Implement TargetLowering::getScalingFactorCost hook.

[Chandler Carruth]

On Sat, Apr 26, 2014 at 2:41 PM, Chris Lattner <clattner at apple.com> wrote:

> On Apr 25, 2014, at 7:53 PM, Chandler Carruth <chandlerc at google.com>
> wrote:
>
> With my current prototype, I see up to 30% speed up on small kernels.
>>
>
> Cool.
>
> My only concern are the cases where not doing the scale requires more
> instructions. In particular, I have seen a lot of performance problems in
> the past[1] which stemmed essentially from using lea to do address
> computations so that the addressing mode operand was simpler. Just want to
> make sure the LSR and other users of this will be sufficiently conservative.
>
> [1]: So fun story here. The fact that LLVM so aggressively forms complex
> addressing modes may explain why this used to be such a big problem for me.
> It would use every single part of the addressing mode in structuring the
> loop body, and then during instruction selection we would fail in a large
> number of cases to match that as an actual addressing mode. I spent a bunch
> of time teaching the instruction selection layer for x86 to re-constitute
> every addressing mode it could in order to fix this. This may even become
> relevant, because while I *tried* to only do these heroics for cases that
> were strictly better (ie, fewer instructions total), I could have messed it
> up, and we might re-form complex addressing modes even when unnecessary.
>
>
> The "right" answer here is to introduce a new llvm intrinsic to represent
> addressing modes.  It is ridiculous that LSR and CGP generate LLVM "very
> carefully" with the expectation that selection dag will be able to
> reconstitute it... and that nothing between them will mess things up.
>

Well, if this is a problem, it isn't the problem I hit. ;] I dunno that we
need this at this point as i've not seen any problems with information loss
between LSR and the DAG.

The problem I hit was the *DAG* destroying the information because it is
represented as arbitrary math in the DAG and we have a bunch of DAG
combines for math. If you want to make the problem I observed better, the
way to do so is to introduce an addressing mode DAG node (or kill off the
DAG completely).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140426/fc30ea33/attachment.html>