On Jan 30, 2012, at 10:08 AM, Devang Patel wrote:> > On Jan 27, 2012, at 5:00 PM, Dan Gohman wrote: > >> Not all of these are miscompiles, > > None I'd say, may be TBAA.Then you missed value ranges and fpaccuracy. Anyway, here are some examples of optimizations which aren't implemented yet, but which have been seriously considered: metadata to mark C++ copy constructors, to allow the optimizer to eliminate them. Metadata to mark C++ vtble pointers, to facilitate devirtualization. Metadata to implement loop pragmas, like "ivdep". Metadata to annotate floating-point operations compiled with flags like -ffinite-math-only. All could be made to cause miscompiles by valid optimizations.> >> but the point is that valid but >> naive optimizations can cause them to be actively misleading > > ... but not cause mis-compilation. Note, optimization passes are free to update info conveyed through MDNodes, if they want to. The "optional to update" while still preserving _correctness_ of the program is a key property of MDNodes.Even if we single out TBAA, recall that TBAA was one of the main motivations for the design of MDNodes -- it's in the second sentance, and most of the last paragraph, of http://blog.llvm.org/2010/04/extensible-metadata-in-llvm-ir.html> Regarding, TBAA you say that this optionality is not optional. If you insist that all transformation passes in pipeline _must_ ensure correctness of alias info conveyed by front end as part of TBAA then I guess you need an explicit mechanism anyway. In that case, I'd encourage you to develop a representation that meets needs instead of twisting MDNodes. In other words, I'd not support direction where all transformation passes are _required_ to preserve semantics of any information encoded through MDNodes. That's all.Let's consider whether LLVM's TBAA is really designed wrong. The only thing you need to know to understand the TBAA issue here is that TBAA properties are associated with memory accesses, rather than with pointer values, because that's how the TBAA rules in the C standard are stated. I've shown how MDNodes attached to load and store instructions can be confounded by otherwise valid optimizations. If you really want to claim that it's possible to implement TBAA or any metadata-based optimization without making optimizers responsible for keeping it up to date, please show me how to do it. Dan
On Jan 30, 2012, at 11:34 AM, Dan Gohman wrote:> Even if we single out TBAA, recall that TBAA was one of the main > motivations for the design of MDNodes -- it's in the second sentance, > and most of the last paragraph, of > http://blog.llvm.org/2010/04/extensible-metadata-in-llvm-ir.html... and in last paragraph the author says ... "This use of metadata is also safe, because it is an optimization: if the type tag gets dropped, it is always safe to assume that the access aliases everything for TBAA purposes." (Not this blog entry was written before TBAA was implemented)>> Regarding, TBAA you say that this optionality is not optional. If you insist that all transformation passes in pipeline _must_ ensure correctness of alias info conveyed by front end as part of TBAA then I guess you need an explicit mechanism anyway. In that case, I'd encourage you to develop a representation that meets needs instead of twisting MDNodes. In other words, I'd not support direction where all transformation passes are _required_ to preserve semantics of any information encoded through MDNodes. That's all. > > > Let's consider whether LLVM's TBAA is really designed wrong. > > The only thing you need to know to understand the TBAA issue here > is that TBAA properties are associated with memory accesses, rather > than with pointer values, because that's how the TBAA rules in the > C standard are stated. > > I've shown how MDNodes attached to load and store instructions can > be confounded by otherwise valid optimizations.What I fail to understand is why can't you use Constant, GlobalVariable, OptDataNode (or TBAANode or something like that) ? Why insist on MDNode ?> If you really want to claim that it's possible to implement TBAA > or any metadata-based optimization without making optimizers > responsible for keeping it up to date, please show me how to do it.I am not. In fact, are you suggesting that it is not possible to implement TBAA without using MDNode ? Anyway, I'll stop the thread here from my side. - Devang
On Jan 30, 2012, at 11:59 AM, Devang Patel wrote:> > On Jan 30, 2012, at 11:34 AM, Dan Gohman wrote: > >> Even if we single out TBAA, recall that TBAA was one of the main >> motivations for the design of MDNodes -- it's in the second sentance, >> and most of the last paragraph, of >> http://blog.llvm.org/2010/04/extensible-metadata-in-llvm-ir.html > > ... and in last paragraph the author says ... > "This use of metadata is also safe, because it is an optimization: if the type tag gets dropped, it is always safe to assume that the access aliases everything for TBAA purposes."[…]> What I fail to understand is why can't you use Constant, GlobalVariable, OptDataNode (or TBAANode or something like that) ? Why insist on MDNode ?[…]> In fact, are you suggesting that it is not possible to implement TBAA without using MDNode ?The the rest of the paragraph you quoted above describes how to implement TBAA in LLVM. The current implementation of TBAA in LLVM follows this, in every detail. The sentence you quote claims that this approach is safe. The current implementation is indeed safe in the sense discussed in the blog entry: if metadata gets dropped, or if only some of it gets dropped, the TBAA pass does behave conservatively. However, while this is necessary for saftey, it is not sufficient. The blog post does not discuss saftey in the case where metadata has *not* been dropped when it needed to be. The only way to make it safe is to make all optimization passes aware of it, at least in some way. I know that the blog entry says this wouldn't be needed, but it's wrong. Dan