On Jan 27, 2012, at 3:40 PM, Devang Patel wrote:> [ removing cfe-dev from the cc list ] > > On Jan 27, 2012, at 1:31 PM, Dan Gohman wrote: > >> On Jan 27, 2012, at 11:20 AM, Devang Patel wrote: >> >>> >>> On Jan 26, 2012, at 2:10 PM, Dan Gohman wrote: >>> >>>> On Jan 26, 2012, at 12:54 PM, Devang Patel wrote: >>>>> >>>>> On Jan 26, 2012, at 11:15 AM, Dan Gohman wrote: >>>>> >>>>>> or what optimizers must do to preserve it. >>>>> >>>>> The number one reason behind metadata is to have a mechanism to track values while being completely transparent to optimizer. If you want a guarantee from the optimizer to preserve certain semantics about the way metadata is used (e.g. say to describe range of values) then metadata is not appropriate mechanism. >>>> >>>> If the optimizer makes no guarantees whatsoever, then metadata is >>>> not appropriate for anything. >>> >>> Are you sure ? :) >> >> Show me an example of a supposedly valid use of metadata, and I'll show >> you a valid optimization which breaks that metadata. > > Your argument of "If TBAA can not use then nobody can" neither helps discussion nor helps avoid confusion. If nobody uses MDNode the way it is designed then eventually they will disappear from llvm. Don't worry.TBAA is one example. My value-range example was another. Here are some more: dbg: If someone mutates an instruction in place, it may not produce the value that the metadata was intended for. fpaccuracy: If the optimizer CSE's two operations with different accuracies, it might happen to keep the less accurate one. prof: If a branch condition is inverted, the frequency data is backward. nontemporal: If the optimizer cache-blocks a loop, it could greatly reduce the amount of time before a stored value is reloaded. Not all of these are miscompiles, but the point is that valid but naive optimizations can cause them to be actively misleading -- profiling data that says the exact opposite of what the code does, or debuggers that think they know what the value of a variable is at a given location but have the wrong value. Dan
On Jan 27, 2012, at 5:00 PM, Dan Gohman wrote:> Not all of these are miscompiles,None I'd say, may be TBAA.> 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. 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. - Devang -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120130/657df196/attachment.html>
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