[LLVMdev] [RFC] Module Flags Metadata

Dan Gohman gohman at apple.com
Fri Jan 27 17:00:58 PST 2012


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




More information about the llvm-dev mailing list