Paul Koning <paulkon...@comcast.net> writes: >> I see. As we do not explicitely model this dependency we probably get lucky >> by the if (gimple_has_volatile_ops ()) bail-out; most passes do. > > That sounds scary, if I understood you correctly. It sounds like GCC > conforms to the standard only by accident rather than by design, which means > that it might stop conforming to the standard by accident. Does this need > cleanup -- for example, explicitly modeling the required sequencing so > optimization passes are more likely to see that and get it right? > > For that matter, if "most" passes do, does that mean that we already have a > bug if some pass that doesn't do this happens to get presented with a > suitably constructed input?
This is a matter of how gcc has evolved over the years. It is certainly the case that gcc is designed to support volatile operations as defined by the standard. What Richard is referring to is a notion of explicit dependencies between instructions, which did not exist for the first 10 or 15 years of gcc's life. These explicit dependencies are now used to model things like memory aliasing which gcc did not support in the early days. The volatile qualifier remains supported, by design, just as it always has been, by checks for volatile in low-level routines. E.g., search for volatile (or VOLATILE) in gcc/alias.c. There are indeed GIMPLE level passes which need to explicitly check gimple_has_volatile_ops. That would remain true whether or we not we do a better job of expressing volatile dependencies explicitly. It would be better to have explicit volatile dependencies. But it is not a requirement for generating correct code. It is of course possible that there are bugs in the way that gcc handles volatile. Since many people use gcc in areas that require volatile to be handled correctly, not least the Linux kernel developers, I would expect such bugs to be reported quickly. Note that the issue that started this thread is not a case in which gcc is mishandling volatile in general. It is an AVR specific issue in which the AVR backend and the gcc combine pass disagree on how volatile memory operands should be handled. Ian
