[LLVMdev] [RFC] Module Flags Metadata

[Dan Gohman]

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