[PATCH] D24918: [ADCE] Add code to remove dead branches

[Mehdi Amini via llvm-commits]

> On Oct 1, 2016, at 1:36 PM, Daniel Berlin <dberlin at dberlin.org> wrote:
> 
> 
> 
> On Sat, Oct 1, 2016 at 9:25 AM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote:
> 
>> On Oct 1, 2016, at 9:22 AM, Daniel Berlin <dberlin at dberlin.org <mailto:dberlin at dberlin.org>> wrote:
>> 
>> 
>> 
>> On Sat, Oct 1, 2016, 9:36 AM David Callahan <dcallahan at fb.com <mailto:dcallahan at fb.com>> wrote:
>> david2050 added inline comments.
>> 
>> 
>> > dberlin wrote in ADCE.cpp:217
>> > I don't think this does what you think.
>> > The order here is not actually guaranteed to be in any particular order, AFAIK.
>> >
>> > It happens most things produce blocks in lexical order, but this is not guaranteed (again, AFAIK)
>> >
>> > Thus, it's entirely possible you see a successor before a predecessor, which you will incorrectly mark a a back edge.
>> > Please just use a standard DFS approach that is guaranteed correct.
>> 
>> This seems super simple and conservative in the sense it will catch all loops. 
>> 
>> 
>> No actually, it will operate completely inconsistently unless bitcode guarantees an order.
> 
> Order of basic-blocks is guaranteed when round-tripping to bitcode (We really try to avoid relying on other *use-list* though).
> 
> Is it also guaranteed that no matter what order they are produced in by the frontend, they are in the same order once read in?

No: the frontend decide the initial order, LLVM has no guarantee over this order, and transformations are free to reorder at will, I was just clarifying the bitcode state: round-trip won’t change the order.

— 
Mehdi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161001/77ef9ba4/attachment.html>