<div dir="auto"><div><br><div class="gmail_extra"><br><div class="gmail_quote">On 30 Jan. 2018 3:35 pm, "Dave Airlie" <<a href="mailto:airlied@gmail.com">airlied@gmail.com</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="elided-text">On 30 January 2018 at 06:33, Dave Airlie <<a href="mailto:airlied@gmail.com">airlied@gmail.com</a>> wrote:<br>
> On 30 January 2018 at 06:25, Gert Wollny <<a href="mailto:gw.fossdev@gmail.com">gw.fossdev@gmail.com</a>> wrote:<br>
>> Am Montag, den 29.01.2018, 20:32 +0100 schrieb Roland Scheidegger:<br>
>>><br>
>>> Am I correct assuming that for something like<br>
>>>    while (foo) {<br>
>>>       if (bar) {<br>
>>>          do something;<br>
>>>       } else {<br>
>>>          /* nothing */<br>
>>>       }<br>
>>>    }<br>
>>> The else clause wouldn't get optimized away neither?<br>
>>> (This of course is a trivial example, but I suppose it would extend<br>
>>> to cases where the optimizer actually optimized away the alu<br>
>>> instructions in the else clause).<br>
>>> In this case, this indeed looks rather harsh.<br>
>> This is indeed the case (unless the if is eliminated completely in the<br>
>> if_conversion).<br>
>><br>
>>> I would have said in theory somehow the break should be some op which<br>
>>> (despite not having a dst) has side-effects so it would not be<br>
>>> subject to elimination somewhere (as there would be a if->next node<br>
>>> in this case then).<br>
>> It is the else that vanishes, but only if there is only a break in the<br>
>> else path, if there there is also an ALU clause, then the else branch<br>
>> is created propperly.<br>
>><br>
>>> Albeit I'm completely oblivious how it really gets optimized away, is<br>
>>> that based on liveness analysis or something? The sb code is a<br>
>>> mystery to me...<br>
>> I'm trying to understand it, but is is very dificult to grasp how it<br>
>> works even with the debugging output. Well, maybe Dave has a better<br>
>> idea.<br>
>><br>
><br>
> I'm reading the paper the whole depart region stuff is based on today,<br>
> maybe I'll come out enlightened or more confused.<br>
><br>
<br>
</div>I'm more confused, but I've attached a patch that I think works, but I'm not<br>
sure it doesn't blow up the world, and I have to head off now.<br>
<font color="#888888"></font></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">I think this may need to check repdep1 region is not the same as the overall region we are processing, or maybe it just needs to check if it's a loop.</div><div dir="auto"><br></div><div dir="auto">Dave.</div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><font color="#888888"><br>
Dave.<br>
</font></blockquote></div><br></div></div></div>