On 01/09/2018 08:29 AM, Richard Earnshaw (lists) wrote: > I'm in two minds about that. There are certainly cases where you might > want to use the generic expansion as part of handling a case where you > have a more standard speculation barrier; in those cases you might want > to emit your barrier and then let the generic code expand and provide > the logical behaviour of the builtin. > > However, if you don't have a barrier you need to ask yourself, will my > architecture ever have an implementation that does do speculation? > Unless you can be certain that it won't, you probably need to be warned > that some code the programmer thinks might be vulnerable to spectre has > not been compiled with that protection, otherwise if you run that code > on a later implementation that does speculate, it might be vulnerable. > > Let me give an example, we use the generic code expansion if we > encounter the builtin when generating code for Thumb on pre-ARMv7 > devices. We don't have instructions in 'thumb1' to guard against > speculation and we really want to warn users that they've done this (it > might be a mistake in how they're invoking the compiler). > > I could add an extra parameter to the helper (bool warn_unimplemented), > which would be true if called directly from the expanders, but would now > allow back-ends to implement a trivial variant that just suppressed the > warning. They could also then use the generic expansion if all that was > needed was a subsequent fence instruction. Yea, I see your side as well on this -- advisable or not I suspect we're going to see folks saying "my embedded chip doesn't have these problems, I don't want to pay any of these costs" and I don't want to be warned about a problem I know can't happen (today).
Anyway, I think relatively speaking this is minor compared to the stuff we're discussing around the semantics of the builtin. I can live with iterating on this aspect based on feedback. jeff