[cfe-commits] [PATCH] llvm.annotation support

[John McCall]

On Jun 21, 2011, at 10:44 PM, Julien Lerouge wrote:
> Sorry for the late reply...

It's your feature, so it's your timetable. :)

> On Fri, Jun 17, 2011 at 04:57:22PM -0700, John McCall wrote:
>> On Jun 14, 2011, at 12:14 AM, Julien Lerouge wrote:
>> +  assert(D->hasAttr<AnnotateAttr>() && "no annotate attribute");
>> +  for (ann_iterator ai = ann_begin(D), ae = ann_end(D); ai != ae; ++ai)
>> +    EmitAnnotationCall(CGM.getIntrinsic(llvm::Intrinsic::var_annotation),
>> +                       Builder.CreateBitCast(V, CGM.Int8PtrTy, V->getName()),
>> 
>> Hoist this bitcast out of the loop, please.
> 
> I'd rather keep this here for now, to keep the IR consistent with
> what llvm-gcc was doing. The reason is that those annotations are meant
> to be consumed by a mid level optimization pass, so I don't want to
> break any existing code that might expect those casts (I know we have
> such code around here unfortunately).
> 
> I can add a FIXME, and I'll get back to it once my project has finished
> the transition to clang. Would that be acceptable ?

A FIXME would be fine, or any sort of comment that makes it clear that
having the redundant bitcasts is intentional.  Although, unless you run your
optimization passes before GVN, I don't know how you expect them to
survive anyway.

>> +  assert(D->hasAttr<AnnotateAttr>() && "no annotate attribute");
>> +  const llvm::Type *ArgTy = CGM.Int8PtrTy, *VTy = V->getType();
>> +  llvm::Value *F = CGM.getIntrinsic(llvm::Intrinsic::ptr_annotation, &ArgTy, 1);
>> +
>> +  for (ann_iterator ai = ann_begin(D), ae = ann_end(D); ai != ae; ++ai) {
>> +    // Always emit the cast inst so we can differentiate between annotation on
>> +    // the first field of a struct and annotation on the strut itself.
>> 
>> I guess this is how this has "traditionally" been represented, but there has
>> got to be a better way of encoding that in the IR.
> 
> Yes. I will most likely spend more time to improve this later on. My
> goal for now was to get clang to generate the same kind of IR llvm-gcc
> was doing.

Understandable.

John.