On Fri, Oct 15, 2021 at 8:35 PM Alexandre Oliva <ol...@adacore.com> wrote: > > 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.
Yes, it is (just having had a quick look most of the functions in the pass lack function-level comments). > 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. I think this has been suggested before, yes. But if those "plugins" are as self-contained as yours here there's also no reason to not simply compile them in as regular passes (unless they are slightly broken and thus a maintainance burden). Richard. > -- > 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>
