similar to: [RFC] We are running out of slots in the Attribute::AttrKind enum

There are two 64-bit bitmasks maintained in AttributeImpl.h<https://sdocc.itg.ti.com/ui#file:review=11893/version=393846>: - AvailableFunctionAttrs is part of the AttributeListImpl class, and - AvailableAttrs is part of the AttributeSetNode class Both of these assume that the number of available enum attributes is limited to 64. In fact, a static_assert in

Hi everyone, We are using the llvm2cpp feature of LLVM in the VMKit project and there are some issues that I would like to point out. I made a tiny reproducible example here, to be clear: echo "int main() { return 0; };" > test.c && clang test.c -emit-llvm -c -o - | llc -march=cpp -cppgen=function -cppfor=main -o - This command is supposed to generate the C++ code to

Hi Sean, I think it can go in as it is. It's a good start. Thanks, Joe! -bw On Feb 9, 2013, at 9:46 PM, Sean Silva <silvas at purdue.edu> wrote: > This looks like a good starting point. I would prefer to call it HowToUseAttributes.rst though (it is essentially a HowTo). > > Bill, is it ok to commit this, or would you like cook up something different to go into the docs?

On 08/24/2017 09:40 AM, Tim Northover wrote: > On 17 August 2017 at 15:15, Rodney M. Bates via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> For an indirect call, i.e., on a function whose address is runtime variable, >> I can't find any place/way to attach this attribute. LLVMAddAttribute >> won't take a type. > > In the C++ API you'd add the

+Bill who worked on the attribute change On Mon, Mar 25, 2013 at 9:15 AM, Harris BAKIRAS <h.bakiras at gmail.com> wrote: > Hi everyone, > > We are using the llvm2cpp feature of LLVM in the VMKit project and there are > some issues that I would like to point out. > > I made a tiny reproducible example here, to be clear: > > echo "int main() { return 0; };"

Cool I renamed it, per Sean's suggestion, to HowToUseAttributes. Committed as r174961 The doc should be live now: http://llvm.org/docs/HowToUseAttributes.html Cheers, Joe Abbey On Feb 12, 2013, at 3:26 AM, Bill Wendling <wendling at apple.com<mailto:wendling at apple.com>> wrote: Hi Sean, I think it can go in as it is. It's a good start. Thanks, Joe! -bw On Feb 9,

Thanks David, I have tried ‘MF.getFunction()->hasFnAttribute(Attribute::???)’, but it seems that the front-end ‘NoInstrumentFunction’ attribute is not propagated to the collection of LLVM IR attributes (no equivalent is in the ‘Attribute::AttrKind’ enum). It is not obvious that there is another mechanism, and I suspect that there is not due to the separation between FE processing and LLVM

Hi Paul, Regarding the "No Touchie!" constraint idea for asm statements: would this be a new qualifier (like volatile) that could be applied to the asm statement? Since the constraint is not necessarily associated with an input or output operand, it seems that introducing the constraint via the qualifier field might work. All, The volatile qualifier on an asm statement already

I would like to add something to atttributes.h, attributes.cpp in the interim until your full scheme is available. A new attribute called "target" would be added to AttrKind. And target can take a list of strings. target("foo", "goo") For example. I would add a component targetAttrs to AttrBuilder Will this meet with resistance if I try and put this back? Reed

The team I am working with is using asm statements containing label definitions as a way of instrumentation so that when an application is loaded into their debug and test framework, the labels will cause breakpoints to be set at strategic points where they can query the state of the processor that the application is running on. ~ Todd From: Eli Friedman [mailto:efriedma at quicinc.com] Sent:

Could this issue also be related to an “AphrontQueryException #1030: Got error 28 from storage engine” error when browsing Phabricator? ~ Todd Snider From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Hubert Tong via llvm-dev Sent: Friday, May 1, 2020 9:15 AM To: Mircea Trofin Cc: Nicolai Hähnle via llvm-dev Subject: [EXTERNAL] Re: [llvm-dev] arc diff says "disk is

*From: *Snider, Todd <t-snider at ti.com> *Date: *Thu, May 9, 2019 at 3:53 AM *To: *Rui Ueyama, James Y Knight *Cc: *llvm-dev > > James, Rui, > > > > If we are only talking about addressable hardware registers, peripherals, > etc., then the absolute address symbol is one way to facilitate access to a > symbol associated with a specific address. > > > >

Looks like new attribute work is moving along quickly Maybe I should just wait. ??? On 01/11/2013 03:09 PM, Reed Kotler wrote: > I would like to add something to atttributes.h, attributes.cpp in the > interim until your full scheme is available. > > A new attribute called "target" would be added to AttrKind. > > And target can take a list of strings. > >

Hi David: >> How do you deal with basic blocks which appear to be used by multiple parts >> of the coroutine? We handled this in WinEHPrepare by cloning any BBs which >> were shared. I experimented with several approaches, but, cloning ended up being the simplest and most reliable. Suspend points express three different control flows that can happen at the suspend point: a

In llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp, the compiler can emit a DW_AT_calling_convention attribute with a DW_TAG_class_type (and it looks like a DW_TAG_variant_part, DW_TAG_structure_type or DW_TAG_union_type as well), but the DWARF 4 specification says that DW_AT_calling_convention is not a valid attribute for any of those three DWARF tags. Downstream object consumers that check to verify

I have the same question as James has. It seems to me that you can name any address using an absolute symbol, and that should suffice to handle memory-mapped peripherals and such. If you really need to define data (whether it's in .data or .bss) or a function at a fixed memory address, that's not something you can do with absolute symbols (but you can do with linker scripts), but is this

I did a RelWithDebInfo + asserts build of LLVM just now and, when running "make check" under Valgrind, am seeing a lot of uses of uninitialized memory like the one below. Anyone know offhand what's likely to be the root cause? Unfortunately a Debug build doesn't give these errors. Thanks, John FAIL: LLVM :: Analysis/BasicAA/pr18573.ll (2093 of 18733)

The attached patch creates a skeleton to expand Attributes documentation in the future. It is currently only linked to the index. Ok to commit? Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130209/e0c7bd7e/attachment.html> -------------- next part -------------- A non-text attachment was

James, What you are doing below is tricking the compiler into believing that it is dealing with a real int object that has actual space allocated to it in x2.o, but sym is not defined as a real data object in x1.o Thanks, but that doesn’t really address my use case. I still contend that associating a placement address with an actual data object (whether it be initialized or not) or function,

> -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of > Adrian Prantl via llvm-dev > Sent: Friday, January 18, 2019 5:20 PM > To: Snider, Todd > Cc: llvm-dev at lists.llvm.org > Subject: Re: [llvm-dev] Potential DWARF debug info bug: DW_TAG_label DIE > has a DW_AT_prototyped attribute > > > > > On Jan 18,