On December 4, 2015 5:20:52 PM GMT+01:00, Jeff Law <l...@redhat.com> wrote: >On 12/04/2015 03:19 AM, Richard Biener wrote: >> On Thu, Dec 3, 2015 at 6:54 PM, Jeff Law <l...@redhat.com> wrote: >>> This is something I noticed while working on fixing 67816. >>> >>> Essentially I was seeing trivially true or trivially false >conditionals left >>> in the IL for DOM to clean up. >>> >>> While DOM can and will clean that crud up, but a trivially true or >trivially >>> false conditional ought to be detected and cleaned up by >cleanup_cfg. >>> >>> It turns out the reassociation pass does not schedule a CFG cleanup >even in >>> cases where it optimizes a conditional to TRUE or FALSE. >>> >>> Bubbling up an indicator that we optimized away a conditional and >using that >>> to trigger a CFG cleanup is trivial. >>> >>> While I have a slight preference to see this fix in GCC 6, if folks >object >>> and want this to wait for GCC 7 stage1, I'd understand. >>> >>> Bootstrapped and regression tested on x86_64-linux-gnu. >>> >>> OK for the trunk? >> >> Ok. [I always hoped we can at some point assert we don't have >trivially >> optimizable control flow in the IL] >Presumably verification when a pass has completed, but not set >TODO_cleanup_cfg?
Well, kind-of, yes. Richard. >Jeff
