[PATCH][instcombine]: Slice a big load in two loads when the element are next to each other in memory.

[Owen Anderson]

On Oct 7, 2013, at 5:37 PM, Quentin Colombet <qcolombet at apple.com> wrote:

> Hi Owen,
> 
> New patch attached.
> 
> The new patch now check if a bitcast is expected to be expensive or not. I.e., it adds in canMergeExpensiveCrossRegisterBankCopy the following check:
>     // At this point, we know that we perform a cross-register-bank copy.
>     // Check if it is expensive.
>     const TargetRegisterInfo *TRI = TLI.getTargetMachine().getRegisterInfo();
>     // Assume bitcasts are cheap, unless both register classes do not
>     // explicitly share a common sub class.
>     if (!TRI || TRI->getCommonSubClass(ArgRC, ResRC))
>       return false;
> 
> Instead of doing this, I can add a target hook that tells how expensive it is (or is it expensive) to bitcast from both register classes.
> I did not go into that direction, because I was afraid that we will push for more cost modeling in target lowering if we do that. Indeed, if we do give a cost, instead of the proposed heuristic or instead of a "is expensive” target hook, we will have to add the cost of loads so that the cost model makes sense.
> 
> Anyway, does the cost model make more sense with the modification and my previous explanations?

Thanks for looking at this, it's definitely an improvement.

I remain concerned about some of the other aspects, in particular the decision to split the load rather than simply move it into the vector bank altogether, as I expressed in my other email.

--Owen