On Oct 14, 2021, Richard Biener <richard.guent...@gmail.com> wrote: > Yeah, I think that eventually marking the operation we want to preserve > (with volatile?) would be the best way. On GIMPLE that's difficult, > it's easier on GENERIC (we can set TREE_THIS_VOLATILE on the > expression at least), and possibly also on RTL (where such flag > might already be a thing?).
Making the expr volatile would likely get gimple to deal with it like memory, which would completely defeat the point of trying to avoid a copy. RTL has support for volatile MEMs and (user-)REGs indeed, but in order to avoid the copy, we don't want the pseudo to be volatile, we want specific users thereof to be. An unspec_volatile would accomplish that, but it would require RTL patterns to match it wherever a pseudo might appear. Considering all forms of insns involving conditionals on all relevant targets, that's far too much effort for no measurable beenefit. > So when going that way doing the hardening on RTL seems easier (if you > want to catch all compares, if you want to only catch compare + jump > that has your mentioned issue of all the different representations) It's not. RTL has various ways to represent store-flags too. Even now that we don't have to worry about implicit CC, a single boolean test may expand to a compare-and-set-[CC-]reg, and then a compare-and-store-CC-reg, or a single compare-and-set-[non-CC-]reg, and IIRC in some cases even more than one (pair of) conditionals. Compare-and-branches also come in such a multitude of settings. It all depends on the target, and I don't really see any benefit whatsoever of implementing such trivial gimple passes with all the potential complexity of RTL on all the architectures relevant for GCC, or even for this project alone. > Note that I did not look on the actual patch, I'm trying to see whether > there's > some generic usefulness we can extract from the patchs requirement > which to me looks quite specific and given it's "hackish" implementation > way might not be the most important one to carry on trunk (I understand > that AdaCore will carry it in their compiler). It's also simple, no-maintenance, and entirely self-contained. A good example of something that could be implemented as a plugin, except for command-line options. Maybe we could have a plugin collection in our source tree, to hold stuff like this and to offer examples of plugins, and means to build select plugins as such, or as preloaded modules into the compiler for easier deployment. -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>
