search for: visoiu

Hi All, I wrote a very crude and simple AsmParser for my backend. llvm-tablegen also generates asm-matcher .inc file without any error. I have included the .inc file in my class for AsmParser. However, while building llvm, in linking stage for LTO, i am getting error - undefined reference to functions - ComputeAvailableFeatures, MatchInstructionImpl, MatchRegisterName and

...wrap will break that many tools, considering the fact that gcc has a good shrink wrapping pass and shrink-wrap-separate pass. Also, if possible, would you be able to share some performance numbers you get back then by improving shrink-wrap? Thanks, Jimmy -----Original Message----- From: Francis Visoiu Mistrih [mailto:francisvm at yahoo.com] Sent: Thursday, May 14, 2020 7:30 PM To: Jimmy Zhongduo Lin <jimmy.zhongduo.lin at huawei.com> Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] RFC] Shrink-wrapping improvement Hi Jimmy, > On May 13, 2020, at 2:25 PM, Jimmy Zhongduo Lin via...

Hi, Sorry for bringing back such an old thread. I am interested in the latest status of the shrink wrapping pass in LLVM. I have found some active work back in 2017 from Francis Visoiu Mistrih and Kit Barton from the following links. However, it seems that all the work suddenly stops and the improvement for the existing shrink wrapping did not make it into the trunk. Is this work abandoned? https://lists.llvm.org/pipermail/llvm-dev/2017-August/116131.html http://lists.llvm.org/p...

Cool this is better than I expected - I never thought about the YAML support. And the document reference is really very good. Thanks Francis, MartinO -----Original Message----- From: Francis Visoiu Mistrih [mailto:francisvm at yahoo.com] Sent: 05 February 2018 21:43 To: Martin J. O'Riordan <MartinO at theheart.ie> Cc: LLVM Developers <llvm-dev at lists.llvm.org>; Adam Nemet <anemet at apple.com> Subject: Re: [llvm-dev] Dumping the static stack reservation sizes for func...

Hi LLVM developers, llc -march=mips -debug-only=isel was able to work in Nov 8 2017 https://reviews.llvm.org/D39723 But it doesn't work now: $ clang --version LLVM China clang version 6.0.0 (git at github.com:llvm-mirror/clang.git 9b7b03045ee9b5622028537266aafeb9ea218ac1) (git at github.com:llvm-mirror/llvm.git 3a26601a88394c02603b8756527c55df9ab94d78) (based on LLVM 6.0.0svn) Target:

Hi, We have a significant regression since llvm 5.0.0 in the x86 assembler. The following snippets fail: 1) .intel_syntax 0: jmp 0b 2) .intel_syntax and edi, 0b010101 when running through `llvm-mc -arch x86-64`. This regression was introduced in r301390, which was driven by PR27884. I think https://llvm.org/PR36144 describes this very well, and I think we should get this fixed, since

...nd. Is the latter technically a bug, maybe, and it so happens nothing is hindered by the absence of the MachineMemOperand, so we're not observing it? Added Elena, based on commit log in X86ISelLowering.cpp, perhaps she has more context. Thanks! Mircea On Thu, Mar 8, 2018 at 2:09 PM Francis Visoiu Mistrih <francisvm at yahoo.com> wrote: > Hello Mircea, > > > On 8 Mar 2018, at 18:52, Mircea Trofin via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Hello, > > > > I'm trying to understand the relationship between MachineMemOperand...

Hi all, We've seen several examples recently of performance opportunities on POWER if we can improve the location of save/restore code for callee-saved registers. Both Nemanja and myself have discussed this with several people, and it seems that there are two possibilities for improving this: 1. Extend shrink wrapping to make the analysis of callee-saved registers more precise. 2.

...ut I haven’t internalized the subtleties yet. I’ll have to get back to you about this part. -Andy From: anemet at apple.com <anemet at apple.com> Sent: Friday, May 03, 2019 2:27 PM To: Kaylor, Andrew <andrew.kaylor at intel.com> Cc: llvm-dev <llvm-dev at lists.llvm.org>; Francis Visoiu Mistrih <francisvm at apple.com> Subject: Re: [llvm-dev] RFC: Extending optimization reporting Hi Andrew, On Apr 30, 2019, at 2:47 PM, Kaylor, Andrew via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: I would like to begin a discussion about up...

Hi Martin, > On Feb 5, 2018, at 11:46 AM, Martin J. O'Riordan via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I would like to be able to emit a list of functions by name and their fixed stack reservation size information, so that a programmer can gauge how much stack they are likely to need in tightly constrained embedded systems. Despite the rich number of options, the

I would like to be able to emit a list of functions by name and their fixed stack reservation size information, so that a programmer can gauge how much stack they are likely to need in tightly constrained embedded systems. Despite the rich number of options, the only option I can find that is even relatively close is: -warn-stack-size=<uint> Is there some existing way of getting this

...mplifying floating point operations with undef with [his understanding of the conclusion](http://lists.llvm.org/pipermail/llvm-dev/2018-March/121591.html) and now has [four patches up for review](http://lists.llvm.org/pipermail/llvm-dev/2018-March/121699.html). * In response to a question, Francis Visoiu Mistrih gives a [helpful overview](http://lists.llvm.org/pipermail/llvm-dev/2018-March/121684.html) of MachineMemOperand. * Alexandre Isoard [wonders](http://lists.llvm.org/pipermail/llvm-dev/2018-March/121634.html) if anyone is interested in a feature to export IR to a git repo after each pass....

Hello Momchil, (CC’ing more people that could correct me if I’m wrong) Thanks for looking into this. More answers below: > On 9 Apr 2018, at 17:57, Momchil Velikov via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hello, > > So, I have this testcase: > > void f(int n, int x[]) { > if (n < 0) > return; > > int a[n]; >

Hello everyone, In the file *lib/CodeGen/AsmPrinter/AsmPrinter.cpp*, I would like to obtain an MCInst corresponding to its MachineInstr. Can anyone tell me a way to do that? If that is not possible, then, I would like to know if a given MachineInstr is an *lea *instruction and I would like to know if the symbol involved with this lea instruction is a jump-table. For instance, given a

Hello Mircea, > On 8 Mar 2018, at 18:52, Mircea Trofin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hello, > > I'm trying to understand the relationship between MachineMemOperand and, on X86, memory operands of machine instructions. The latter seem to be operands held in order by the MachineInstr, from an offset onwards - Base, Scale, Index, Displacement,

Hello all, During the compilation process, LLVM automatically derives various attributes about functions and values (for example that a pointer is nonnull, a function is constant, etc) that are used within a translation unit. I propose adding a pass to LLVM that allows front-ends to output derived attributes. Such a pass would be useful both for developers and end users to debug programs,

Hi, I'm new to llvm and am trying to run benchmarks from the test-suite using lnt to check loop-vectorization for various benchmarks. Test are compiling and executing fine, but I am not getting optimization remarks while using flags like -Rpass-missed=loop-vectorize and -Rpass-analysis=loop-vectorize I've tried running it like this: lnt runtest test-suite --sandbox SANDBOX --cc

Hello, I'm trying to understand the relationship between MachineMemOperand and, on X86, memory operands of machine instructions. The latter seem to be operands held in order by the MachineInstr, from an offset onwards - Base, Scale, Index, Displacement, Segment. The former, if I understand it correctly, is used to hold a relationship back to IR load/store instructions. Is it possible to have

Hello, So, I have this testcase: void f(int n, int x[]) { if (n < 0) return; int a[n]; for (int i = 0; i < n; i++) a[i] = x[n - i - 1]; for (int i = 0; i < n; i++) x[i] = a[i] + 1; } that, compiled with -O1/-Os for AArch64 and X86, generates machine code, which fails to properly restore the stack pointer upon function return.

...he most part, I believe we could implement the “interpreter” for just a handful of instruction and get 90% of the information right. Cheers, -Quentin > On Feb 14, 2019, at 9:20 AM, Adrian Prantl <aprantl at apple.com> wrote: > > > >> On Feb 13, 2019, at 8:44 PM, Francis Visoiu Mistrih <francisvm at yahoo.com> wrote: >> >> Hi, >> >> [+ Quentin] >> >> Sorry for the late reply. >> >>> On Feb 13, 2019, at 9:09 AM, Nikola Prica <nikola.prica at rt-rk.com> wrote: >>> >>> On 12.02.2019. 18:06,...