> On May 15, 2024, at 02:09, Richard Biener <rguent...@suse.de> wrote: > > On Tue, 14 May 2024, Qing Zhao wrote: > >> >> >>> On May 14, 2024, at 13:14, Richard Biener <rguent...@suse.de> wrote: >>> >>> On Tue, 14 May 2024, Qing Zhao wrote: >>> >>>> >>>> >>>>> On May 14, 2024, at 10:29, Richard Biener <rguent...@suse.de> wrote: >>>>> >>> [...] >>>>> It would of course >>>>> need experimenting since we can end up moving stmts and merging blocks >>>>> though the linear traces created by jump threading should be quite >>>>> stable (as opposed to say the unrolling case where multiple instances >>>>> of the loop body likely will end up in the exact same basic block). >>>> >>>> Do you mean, for loop unrolling the approach with one extra stmt for one >>>> basic block might be even harder and unreliable? >>> >>> The question is whether the stmt marks the whole block or whether we >>> for example add both a START and END stmt covering a copied path. >>> I would guess for unrolling we need definitely need to do the latter >>> (so we can diagnose "on the 3rd iteration of an unrolled loop" or >>> similar). >> >> Okay. I see. >> >> Is it possible that the START and END stmts might be moved around and >> out-of-place by the different optimizations? > > There is nothign preventing stmts to be moved across START or END. Then we have to add some artificial data dependency or memory barrier at START and END to prevent such transformation. However, this might also prevent some useful transformation, therefore impact the performance… Not sure whether this is a good approach…
Yes, some experiments might need to be done to compare the cost of these different approaches. Qing > > Richard.
