[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