[llvm-dev] [CodeGen] PeepholeOptimizer: optimizing condition dependent instrunctions

[Quentin Colombet via llvm-dev]

Hi Evgeny,

> On Mar 9, 2016, at 6:28 AM, Evgeny Astigeevich via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> Hi,
>  
> I find it’s quite strange how condition dependent instructions are processed in PeepholeOptimizer::runOnMachineFunction:
>  
> 01577       if ((isUncoalescableCopy(*MI) &&
> 01578            optimizeUncoalescableCopy(MI, LocalMIs)) ||
> 01579           (MI->isCompare() && optimizeCmpInstr(MI, &MBB)) ||
> 01580           (MI->isSelect() && optimizeSelect(MI, LocalMIs))) {
> 01581         // MI is deleted.
> 01582         LocalMIs.erase(MI);
> 01583         Changed = true;
> 01584         continue;
> 01585       }
> 01586 
> 01587       if (MI->isConditionalBranch() && optimizeCondBranch(MI)) {
> 01588         Changed = true;
> 01589         continue;
> 01590       }
>  
> CmpInstr, SelectInstr and CondBranch are processed separately. It’s assumed that CmpInstr and SelectInstr are deleted but CondBranch is not.
> In fact CmpInstr is always connected to SelectInstr or CondBranch or both of them. So if such connection exists it should be processed as a whole.

This code allows you to do that, unless I am mistaken.

> For example, there are cases when CMP+BRC can be replaced by BR. The same is true for CMP+SEL.

I believe this should be done in respectively optimizeCondBranch and optimizeSelect.

>  
> The main problem I have is that I have to find corresponding CmpInstr and to repeat analysis of it in optimizeSelect and in optimizeCondBranch.

Ok, so basically your concern is that we may call twice analyzeCompare. Is that it?
This function is probably cheap so I wouldn’t be too concerned about that. If I turn out to be wrong, then yes we can think of a better mechanism.

>  
> Any thoughts why it’s implemented in such way.

The idea of the peephole optimizer is top-down approach and greedily applied optimization.

I have to admit I don’t see the concern with the instruction being condition dependent; we don’t want to call optimizeCondBranch :).
I believe I missed your point.

Cheers,
-Quentin

>  
> Kind regards,
> Evgeny Astigeevich
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160309/212f8c8b/attachment.html>