[PATCH] D18634: Don't IPO over functions that can be de-refined
Sanjoy Das via llvm-commits
llvm-commits at lists.llvm.org
Thu Mar 31 10:18:22 PDT 2016
sanjoy added a comment.
In http://reviews.llvm.org/D18634#388277, @rnk wrote:
> Now it occurs to me that there are instrumentation passes like MSan
> that can de-refine code after optimization, and make a readnone
> function into a function that stores to shadow memory. I wonder if
> that matters.
I'd say such "instrumentation" passes are not about de-refinement, but
about adding non-observable behavior (though I don't know exactly what
MSan does).
Another example of this sort of thing is the 'Self healing' in Azul's
LVB (load value barrier) -- semantically it is a load, except that it
may also write to memory in a way that won't change observable
behavior.
> > Note that I think mayBeOverridden will become irrelevant with this change,
>
> > and so I would look closely at removing that or re-using it.
>
>
>
> Well, the inliner still needs mayBeOverridden or some equivalent way
> of separating ODR linkages from non-ODR linkages. It's the only IPO
> transform that everyone agrees is safe for ODR functions.
Another way to split this is into `isStrongDefinition` and
`isReplacableODRDefinition` (I'd rather have written the second one as
`isWeakODRDefinition`, but that's confusing since we already have the
`weak_odr` linkage). Does that sound better?
http://reviews.llvm.org/D18634
More information about the llvm-commits
mailing list