[cfe-commits] [PATCH] llvm.annotation support
John McCall
rjmccall at apple.com
Wed Jun 22 00:19:41 PDT 2011
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.
More information about the cfe-commits
mailing list