similar to: [LLVMdev] How to associate extra comments to a MachineInstruction ?

> From: Eric Christopher > Subject: Re: [LLVMdev] How to associate extra comments to a > MachineInstruction ? > > Should be spelled like this yes? > > Asm->OutStreamer.AddComment("foo") > Asm->EmitFoo(); > > -eric That should work at the moment that you are emitting the instructions. But what would you do when you are manipulating a

On Thu, May 30, 2013 at 2:16 PM, Jeroen Dobbelaere <Jeroen.Dobbelaere at synopsys.com> wrote: >> From: Eric Christopher >> Subject: Re: [LLVMdev] How to associate extra comments to a >> MachineInstruction ? >> >> Should be spelled like this yes? >> >> Asm->OutStreamer.AddComment("foo") >> Asm->EmitFoo(); >> >> -eric

Should be spelled like this yes? Asm->OutStreamer.AddComment("foo") Asm->EmitFoo(); -eric On Thu, May 30, 2013 at 1:44 PM, Jeroen Dobbelaere <Jeroen.Dobbelaere at synopsys.com> wrote: > Hi, > > is there a convenient way to associate/add a comment to a MachineInstruction, so that > in the produced assembly file, the comment is added next to the instruction ?

Ok I think we have some common ground - CSE should choose the aliased pointer over the non-aliased one because we don't want the no-aliasing information to creep outwards from the inlined callsite. I'll put together a patch in the coming days and add y'all as reviewers so you get visibility. Cheers, -Neil. On Wed, Jan 22, 2020 at 4:47 PM Jeroen Dobbelaere < Jeroen.Dobbelaere at

Great, thanks! Are you planning on just talking about these things with slides? Do we have other things to which we can link for people to read? -Hal Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory ________________________________ From: Tarique Islam <tislam at ca.ibm.com> Sent: Thursday, May 21, 2020 8:19:31 AM To:

Thanks, Jeroen, that really helps. A follow-up question, if you don't mind. What if we have code somewhat similar to your example in assign3() but it's in C++ and the pointer derived from x is stored in a class member field: class S { public: S(int *d): data(d) {} int *getData() { return data; } private: int *__restrict__ data; }; void assign4(int *pA, long N) { int

To join our call on Thursday, May 28th @ 9-10 AM central time / 2-3 PM UTC please use this information: Meeting URL https://bluejeans.com/643493129?src=join_info Meeting ID 643 493 129 Want to dial in from a phone? Dial one of the following numbers: +1.312.216.0325 (US (Chicago)) +1.408.740.7256 (US (San Jose)) +1.866.226.4650 (US Toll Free) (see all numbers -

Hi, everyone, We had a great call last month, and progress is definitely being made on several fronts. The notes from our last call are available here: https://docs.google.com/document/d/1ybwEKDVtIbhIhK50qYtwKsL50K-NvB6LfuBsfepBZ9Y/edit#heading=h.vpxs8lkuxy79 and, also, pasted below. DOODLE POLL: As we discussed on our last call, I would like to schedule a regular call to discuss

Hi Alexey, Adding llvm-ir bitcode support means adding/adapting the tags for LOAD/STORE instructions and adding the support for the noalias_sidechannel at the right places. I had a short attempt to implement it when preparing the public patches, but I am not familiar with that part of the llvm code. When I noticed that it would take a lot longer than anticipated, I postponed it. Also because it

Hi, everyone, We've had a number of discussions recently, including on the Flang technical call, about potential improvements to LLVM's alias analysis to support handling restrict and restrict-like semantics. We would like to try having a call to discuss these issues further. Please, if you're interested in joining, indicate your availability (prior to the end of this week):

Hi, I am trying to make my tablegen files more flexible and for that I would like to have a name that in the end will be replaced with a type. If tablegen would support c preprocssing, I would do it like this: --- #define myBaseType i32 ... def imm32 : Operand<myBaseType>; def immZExt10 : ImmLeaf<myBaseType, [{return isUInt<10>(Imm);}]>; ... --- Is there a way to achieve

Hi, everyone, A quick reminder: This call will start in approximately four hours. See below for how to join. On our current agenda: Agenda * Full restrict patch * Observation and clarification * Issues encountered * Speed up in intersection code - O(nlog(n)) * Calling Verifier after LoopVectorize pass? -Hal Hal Finkel Lead, Compiler Technology and Programming

Hi all, I am happy to announce that Synopsys wants to contribute its implementation of 'C99 restrict' to the LLVM project. [1] This implementation is based on Hal Finkel's local restrict patches and on the 'RFC: Full 'restrict' support in LLVM' [2] Any help with extra testing and code review is welcome. To be generally useful, there are also some small gaps [1] that

At a high level, EarlyCSE should be intersecting the metadata of instructions that it combines. If it doesn't, and also doesn't drop the metadata, that seems like a bug, regardless of anything else. On 1/22/20 9:30 AM, Jeroen Dobbelaere wrote: Hi Neil, Hall, - as far as 'C' is concerned, this is input code is valid, as the pointers are not used to modify objects. - as far as

Hi Ivan, The code that we have is indeed different from what the 'standard llvm' expects. Let me explain: in our version we came into this situation in two steps: 1) I added support for 'special types' that map directly to types supported by hardware. These types are represented by a struct containing a single iXXX member, providing the necessary bits of the type, and at the

On 2012 2 2, at 08:40, Jeroen Dobbelaere <Jeroen.Dobbelaere at synopsys.com> wrote: > I was able to get rid of the 'moves' by setting the copycost to -1. > For getting rid of the spills, I was forced to introduce custom nodes, that pass the CC register > through 'glue'. > > Having a property to register classes that identifies a 'glue-like' behavior

Hi Jakob, Jonas et al, Jakob wrote: [...] > Jonas wrote: > [...] > > What's more, setting the GPR_CR class to 'not-spillable' would probably do the trick here as we > > basically do not want to do this, and I would not have to pre-allocate. But there is probably a > > better way, or? > > I am sorry, I simply don't understand what you are asking

Hi, I am investigating a difference in code generation between release and assert builds of llvm. The culprit is IndVarSimplify that comes up with different behavior on the same input: in the assertion build, it does do an extra 'INDVARS: Rewriting loop exit condition' After digging around, it seems that following change is the culprit: ----- Author: Philip Reames <listmail at

DwarfDebug::emitDebugInfo() always appends four zero bytes to the tail of the debug info section: emitDIE(Die); // FIXME - extra padding for gdb bug. Asm->OutStreamer.AddComment("4 extra padding bytes for GDB"); Asm->EmitInt8(0); Asm->EmitInt8(0); Asm->EmitInt8(0); Asm->EmitInt8(0);

Hi Hal, On Fri, Apr 4, 2014 at 12:44 AM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "Jeroen Dobbelaere" <jeroen.dobbelaere at gmail.com> > [... ] > > I am trying to get llvm working for an architecture that has 64bit > > registers, but 32bit addresses. > > Because of that, I want the pointers to also be