> > Also as discussed some time ago, the volatile loads between traps has > > effect of turning previously pure/const functions into non-const which > > is somewhat sad, so it is still on my todo list to change it this stage1 > > to something more careful. We discussed internal functions trap_store > > and trap_load which will expand to load/store + trap but will make it > > clear that side effect does not count to modref. > It's been a long time since I looked at this code -- isn't it the case that > we already must have had a load/store and that all we've done is change its > form (to enable more DCE) and added the volatile marker? > > Meaning that it couldn't have been pure/cost before, could it? Or is it the > case that you want to not have the erroneous path be the sole reason to > spoil pure/const detection -- does that happen often in practice?
I noticed that while looking into cases during GCC bootstrap where function analysis went worse after inlning than before, so it happens in practice. mod-ref can now analyse independently whether function reads/wrotes memory (and what memory) and whether function has other side effects or is non-deterministics. We can now DSE function call if it has no side effects and all memory stores are understood and dead. Problem is that split paths turns undefined behaivour into side effects and blocks this optimization. Honza
