[cfe-dev] [LLVMdev] [RFC] Module Flags Metadata

[Dan Gohman]

On Jan 26, 2012, at 3:02 PM, Hal Finkel wrote:

> On Thu, 2012-01-26 at 14:10 -0800, Dan Gohman wrote:
>> 
>> If the optimizer makes no guarantees whatsoever, then metadata is
>> not appropriate for anything.
>> 
>> For example, the metadata used by TBAA today is not safe. Imagine an
>> optimization pass which takes two allocas that are used in
>> non-overlaping regions and rewrites all uses of one to use the other,
>> to reduce the stack size. By LLVM IR rules alone, this would seem to
>> be a valid semantics-preserving transformation. But if the loads
>> and stores for the two allocas have different TBAA type tags, the
>> tags will say NoAlias for memory references that do in fact alias.
>> 
>> The only reason why TBAA doesn't have a problem with this today is
>> that LLVM doesn't happen to implement optimizations which break it
>> yet. But there are no guarantees.
> 
> On that thought, is there any way that my autovectorization pass could
> invalidate the TBAA metadata (in a harmful way) when it fuses two
> memory-adjacent loads or stores? Currently, it performs this fusion by
> first cloning the first instruction (which I think will pick up its
> metadata), then changing the instruction's type and operands as
> necessary. This fusion will only take place if the two instructions have
> the same LLVM type, but currently there is no check of the associated
> metadata.

Yes, it sounds like this could indeed cause TBAA tags to become invalid,
because it extends the range of memory that a given TBAA tag is associated
with.

Dan