similar to: [LLVMdev] Function Attributes in LLVM

Hello, Josef > useful for some low level targets. As far as I know function > attributes > are GCC specific or am I wrong? That's correct > Is there a Standard-C way to add this > kind of meta information to a function? Well... You can store function pointers into some array and add any extra information your like. > I think it would be a pretty nice feature if a

Thanks for your response! On 30/01/2019 20:18, Rui Ueyama wrote: > Hi Josef, > > Let me clarify my understanding. Do you want to keep original bitcode > files in the output executable when doing LTO, so that the resulting > executable contains both compiled bitcode (which is in native machine > instructions) and original bitcode files? Exactly! Kind of analogous to what

On Thu, Jan 31, 2019 at 11:05 AM Rui Ueyama via llvm-dev < llvm-dev at lists.llvm.org> wrote: > That feature is probably too specific to your project. Most projects that > use LTO are using LTO just because it generates better code. Your project > is special as your program itself can also interpret LLVM bitcode, but > that's not the case for most other programs. > I

Hey, I have written a few lines about Release and Debug Builds (SVN checkout vs. LLVM distribution). I've also added the RELEASE_25 tag to the tags list and corrected a typo. Can someone please review? As I'm not a native speaker/writer it may contain strange wording/spelling mistakes ;). Any feedback welcome. BR Josef -- zapster -------------- next part -------------- A non-text

Hi everybody! I'm Josef and I'm working at Oracle Labs on Sulong [1,2], the LLVM IR execution engine in GraalVM [3]. In addition to executing bare bitcode files, Sulong also accepts ELF files with embedded bitcode sections. Therefore, it would be great if LLD in (Full)LTO mode would support embedding bitcode sections to the resulting object file. Is that something that would be

Hello, seems like GettingStarted.html is outdated regarding the version numbers of the autoconf tools. I've changed it so they meet the versions in AutoRegen.sh. Josef -------------- next part -------------- A non-text attachment was scrubbed... Name: GettingStarted.diff Type: text/x-patch Size: 1514 bytes Desc: not available URL:

David Greene wrote: > On Saturday 01 May 2010 08:34:50 Josef Eisl wrote: >> Hello, >> >> I want learn more about register allocation and do some analysis for a >> current research project. After reading some papers (eg. Chaitin, >> Briggs) I think its time to get my hands dirty :). > > Welcome! > >> First I plan to (re)implement some of the classic

On Nov 29, 2009, at 8:16 AM, Josef Eisl wrote: > Hello, > > seems like GettingStarted.html is outdated regarding the version numbers > of the autoconf tools. I've changed it so they meet the versions in > AutoRegen.sh. Hi Josef, llvm/docs/GettingStarted.html (in the main llvm svn repo) seems up to date. The "website" module in svn is an old broken thing that

On Mon, Oct 17, 2011 at 7:58 AM, James Molloy <james.molloy at arm.com> wrote: > Hi, > > > > Looking at bugzilla PR11087, I’d like to conditionalise a transformation in > ARMIselLowering.cpp based on whether we’re compiling for codesize or > performance. > > > > -Os doesn’t actually exist for llc, and I can’t see an obvious place where > that condition

Hello, I want learn more about register allocation and do some analysis for a current research project. After reading some papers (eg. Chaitin, Briggs) I think its time to get my hands dirty :). First I plan to (re)implement some of the classic approaches to get familiar with the framework. At the beginning the following questions came up: - Is there some documentation about register allocation

On Tuesday 04 May 2010 05:45:36 Josef Eisl wrote: > >> - As far as I understand it, register allocators are implemented as > >> MachineFunctionPasses. Does a MachineFunction object contain all > >> information needed for a (classic) allocator? > > > > It has the instructions, operands and dependencies among them. There's > > a

On Saturday 01 May 2010 08:34:50 Josef Eisl wrote: > Hello, > > I want learn more about register allocation and do some analysis for a > current research project. After reading some papers (eg. Chaitin, > Briggs) I think its time to get my hands dirty :). Welcome! > First I plan to (re)implement some of the classic approaches to get > familiar with the framework. Before

Andrea_DiBiagio at sn.scee.net wrote: > Hi, > > I previously made a proposal for adding a pragma for per-function > optimization level control due to a number of requests from our customers > (See http://comments.gmane.org/gmane.comp.compilers.clang.devel/28958 for > the previous discussion), however the discussion was inconclusive. Some > of my colleagues recently had the

Hi, I previously made a proposal for adding a pragma for per-function optimization level control due to a number of requests from our customers (See http://comments.gmane.org/gmane.comp.compilers.clang.devel/28958 for the previous discussion), however the discussion was inconclusive. Some of my colleagues recently had the opportunity to discuss the proposal with a number of people at and

On Tue, Apr 3, 2018 at 12:47 PM via llvm-dev <llvm-dev at lists.llvm.org> wrote: > All, > A recent commit, D43040/r324557, changed the behavior of the gold plugin > when compiling with LTO. The change now causes the codegen optimization > level to default to CodeGenOpt::Default (i.e., -O2) rather than use the > LTO optimization level. The argument was made that the LTO

Hey all, Could anyone give me any hint on how llvm-g++ translates the "__attribute__" annotations (supported by GCC)? (Has GCC already implemented the support for the C++0x attributes?) Suppose a class definition as below: template <typename T> class __attribute__((may_alias)) list { ... }; I understand that each particular attribute may be handled differently. Assuming that

All, A recent commit, D43040/r324557, changed the behavior of the gold plugin when compiling with LTO. The change now causes the codegen optimization level to default to CodeGenOpt::Default (i.e., -O2) rather than use the LTO optimization level. The argument was made that the LTO optimization level should control the amount of cross-module optimizations done by LTO, but it should not

Sorry, my reply “to all” left out LLVM-Dev From: Martin J. O'Riordan [mailto:MartinO at theheart.ie] Sent: 04 April 2018 16:41 To: 'David Blaikie' <dblaikie at gmail.com>; 'mcrosier at codeaurora.org' <mcrosier at codeaurora.org>; 'Chandler Carruth' <chandlerc at gmail.com>; 'Eric Christopher' <echristo at gmail.com> Subject: RE:

Hi, I'm trying to annotate certain functions in C code, and do something with these functions in my LLVM pass. I annotate the C code like this: int __attribute__((annotate("annot"))) function() { This nicely gets added to the LLVM bitcode in an @llvm.global.annotations global. Now I had hoped that it'd be easy to extract a list of functions annotated with my annotation

On Jun 25, 2008, at 6:33 AM, Matthijs Kooijman wrote: > Hi all, Howdy Matthijs, > I've also been developing an interest in using IR annotations for my > compiler. > Some discussion with Bart turns out that he has implemented some > code to parse > the llvm.globals.annotations array, but in no way integrated or > reusable. > We've spent some thought about how