[LLVMdev] String attributes for function arguments and return values (original) (raw)

Duncan P. N. Exon Smith dexonsmith at apple.com
Tue Jul 21 13:12:16 PDT 2015

On 2015-Jul-14, at 22:15, Eric Christopher <echristo at gmail.com> wrote:

So as far as the attribute versus metadata question here I don't have a particular care whether or not we support attributes on any particular thing in the Value hierarchy. As far as your particular case I really only have one question: are the attributes needed for correctness or for optimization? If they're the latter they should probably be metadata, the former then attributes seem to make the best sense. For the particular use case we have, metadata on arguments would be a better semantic fit. It's a pure optimization hint. Having said that, attributes work just fine in practice as well. I guess as long as they're not upstreamed you can do whatever you'd like, I'd suggest the metadata though just to keep within the llvm design principles. Mostly just trying to see about you getting the right fixes in for the support you need and the rest of us not having to worry about not breaking things that no one cares about :) Let me restate my previous comment: Having support for custom attributes on function arguments is generally useful for external users of LLVM. Whether it is ideal in this particular case is not really relevant. There are certainly reasonable cases where using a target/environment specific attribute to effect call lowering makes perfect sense. It seems desireable to be able to prototype these quickly so that they can mature and (possibly) make it upstream. There's a lot of things that are generally useful that we delete. I don't see anything unused in any other way. Bitcode support is a bit more... solid though so removing anything that exists is harder. Misfeatures or things accidentally supported have a tendency to stick around and complicate things. That said... My view is that we already support these attributes. I don't have an example user, but it really wouldn't surprise me if folks were using this functionality already. Everything works if generated through the C++ APIs or read from bitcode. It's only the deserialization parts that break. In particular, you can have a working compiler which generates output which isn't parseable by LLVM's existing tools. That's not exactly a good state to be in. I don't have a strong opinion here as I said in the first place. If fixing this support is useful then I've no objection.

FWIW (I'm arriving kind of late here...), I agree that string-based attributes make sense to support on arguments.

-eric

-eric

Philip

On Mon, Jul 13, 2015 at 7:42 AM, Artur Pilipenko <apilipenko at azulsystems.com> wrote: Hi, On 13 Jul 2015, at 15:59, Hal Finkel <hfinkel at anl.gov> wrote: ----- Original Message ----- From: "Artur Pilipenko" <apilipenko at azulsystems.com> To: llvmdev at cs.uiuc.edu Cc: "Hal Finkel" <hfinkel at anl.gov> Sent: Monday, July 13, 2015 6:45:35 AM Subject: String attributes for function arguments and return values

Hi, I’d like to support string attributes on function arguments and return values. We are going to use them in our tree to express higher level language types. How do you expect to use this information? Will you need the inliner to do something special with these? Type information is required for Java specific optimizations, like devirtualization, subtype check optimizations, etc. There are no plans to upstream them, because they are too specific to Java. W.r.t inlining I don’t think that these attributes will require any special handling. Artur

Thanks again, Hal

Internally attributes framework have everything to do this, it’s even possible to generate string attributes via API right now: Function *function; function->setAttributes(function->getAttributes().addAttribute(context, i, "attribute")); But because it’s not supported in LLParser if you dump the function and try to parse it back it will fail. I have a patch to fix this problem: http://reviews.llvm.org/D11058 I consider this part as a bug fix for existing functionality. The second patch is to add accessors to string attributes to Argument and Function classes: http://reviews.llvm.org/D10872 This part is optional because there no code in upstream will make use of it. But if we support string attributes syntax it makes sense to provide API support as well. Does anyone have any objections? Thanks, Artur

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

LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

More information about the llvm-dev mailing list