[LLVMdev] Could metadata ever be mandatory for correctness in LLVM IR?

Hal Finkel hfinkel at anl.gov
Fri Jun 19 15:26:08 PDT 2015


----- Original Message -----
> From: "Stephen Cross" <scross at scross.co.uk>
> To: llvmdev at cs.uiuc.edu
> Sent: Friday, June 19, 2015 5:19:33 PM
> Subject: [LLVMdev] Could metadata ever be mandatory for correctness in LLVM	IR?
> 
> Hi everyone,
> 
> Currently it looks like metadata is used in LLVM IR essentially as an
> 'optional extra', in that any pass is allowed to remove metadata
> (though preserving metadata is useful) and the program should remain
> valid. In other words the metadata only communicates information
> about
> code quality or associated information rather than issues relevant to
> correctness.
> 
> First question: Is this is a long term design intention OR something
> that just currently happens to be true?

That is intentional.

> 
> The context for this is that I'm considering how to represent ABI
> information in a language-agnostic way in LLVM IR. I've seen/heard
> some suggestions about using metadata to represent ABI information
> (e.g. to say this 'i32' is actually an 'int'), but it does seem like
> metadata is not intended for this kind of use case since removing the
> metadata would affect the correctness of the lowering in the backend.

We might be able to make different guarantees for module-level metadata, but I'm not certain.

> 
> Second question: Given that context, would it be reasonable to say
> that metadata would not be considered an appropriate mechanism for
> communicating ABI information?

That's right. Is there a reason you can't use function attributes for the ABI information?

 -Hal

> 
> Thanks,
> Stephen
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory



More information about the llvm-dev mailing list