<div dir="ltr">It might be better to simply add an option to SimplifyCFG that defaults to false for doing these individual phi nodes, then other targets wouldn't be affected but could still choice to take advantage of it if they see fit.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 5, 2020 at 8:20 AM Ryan Taylor <<a href="mailto:ryta1203@gmail.com">ryta1203@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Just to be clear, I meant "cmov" as a generic definition of the target supporting some type of conditional mov, not explicitly 'cmov', so it would be target dependent, of course.<div><br></div><div>What I meant is that just because a target supports "cmov" it still might not be beneficial to the target to do the transform, and determining that could be quite complex depending on several things (the target info, target specific backend passes, etc..).</div></div><div dir="auto"></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 5, 2020, 7:58 AM Nicolai Hähnle <<a href="mailto:nhaehnle@gmail.com" target="_blank">nhaehnle@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Feb 5, 2020 at 1:53 PM Ryan Taylor <<a href="mailto:ryta1203@gmail.com" rel="noreferrer" target="_blank">ryta1203@gmail.com</a>> wrote:<br>
> Conditional on the target supporting cmov? Though that's probably not optimal.<br>
<br>
No, it's not. Consider how the condition may be represented depending<br>
on targets (e.g., flag registers....).<br>
<br>
Cheers,<br>
Nicolai<br>
<br>
<br>
><br>
><br>
><br>
> On Wed, Feb 5, 2020, 7:47 AM Nicolai Hähnle <<a href="mailto:nhaehnle@gmail.com" rel="noreferrer" target="_blank">nhaehnle@gmail.com</a>> wrote:<br>
>><br>
>> Hi Ryan,<br>
>><br>
>> On Mon, Feb 3, 2020 at 7:08 PM Ryan Taylor via llvm-dev<br>
>> <<a href="mailto:llvm-dev@lists.llvm.org" rel="noreferrer" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
>> > SimplifyCFG FoldTwoEntryPhiNode looks to simplify all 2 entry phi nodes in a block, if it can't do them all then it won't do any and returns. There is a lot of code that is directly in this function geared toward this requirement. Is it possible currently to get this function (or pass) to simply fold "some" of the phis (without having to fold them all?). I understand that "Simplify"CFG isn't really meant for this type of thing but there is a lot of code that is re-usable to do this with some refactoring of this function and potentially some addition of target specifics.<br>
>> ><br>
>> > For some phis, it's beneficial to keep them as the generated COPYs can be coalesced away later in the pipe. For other phis (for example, phis with all or potentially partial imm ops), it would be nice to opt these to selects (cmovs). It would also be nice to have this opt prior to the rest of SimplifyCFG as it might enable SimplifyCFG to do a better job of simplifying by reducing the number of phis, etc...<br>
>><br>
>> I don't see a significant problem in adding this to<br>
>> FoldTwoEntryPhiNodes. The relevant changes would be isolated to the<br>
>> initial loop over the phis, and would be somewhat parallel to the use<br>
>> of simplifyInstruction.<br>
>><br>
>> The main question is to how to make this conditional on a per-target<br>
>> basis, i.e. how to properly define any relevant heuristics via<br>
>> TargetTransformInfo.<br>
>><br>
>> Cheers,<br>
>> Nicolai<br>
>><br>
>><br>
>><br>
>> --<br>
>> Lerne, wie die Welt wirklich ist,<br>
>> aber vergiss niemals, wie sie sein sollte.<br>
<br>
<br>
<br>
-- <br>
Lerne, wie die Welt wirklich ist,<br>
aber vergiss niemals, wie sie sein sollte.<br>
</blockquote></div>
</blockquote></div>