search for: francisvm

...any 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 llvm-dev <llvm-dev at l...

...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 and, > on X86, mem...

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 functions Hi Martin, > On...

...alized 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 updating LLVM's opt-...

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

...ieve 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, Adrian Prantl wrote:...

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]; >

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?

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.

Hi all, I tried to poke my head into opt-report a while ago and didn't get very far. Now I'm looking at it again. I'm not sure I understand everything that's in place so my question here may be misguided. I'm trying to understand the way strings are handled. When a remark is emitted, it seems that the string is constructed on the fly based on streaming inputs. For example,

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, Adrian Prantl wrote: >> [+ some folks more knowledgable about the Machine layer than me.] >> > That would be useful for us too! :) > > >>> On Feb 12, 2019, at 5:07 AM, Nikola Prica <nikola.prica at

...s, >> -Quentin >> >>> On Feb 14, 2019, at 9:20 AM, Adrian Prantl <aprantl at apple.com >>> <mailto:aprantl at apple.com>> wrote: >>> >>> >>> >>>> On Feb 13, 2019, at 8:44 PM, Francis Visoiu Mistrih >>>> <francisvm at yahoo.com <mailto:francisvm at yahoo.com>> wrote: >>>> >>>> Hi, >>>> >>>> [+ Quentin] >>>> >>>> Sorry for the late reply. >>>> >>>>> On Feb 13, 2019, at 9:09 AM, Nikola Prica <nikola.pr...

I would like to begin a discussion about updating LLVM's opt-report infrastructure. There are some things I'd like to be able to do with optimization reports that I don't think can be done, or at least aren't natural to do, with the current implementation. I understand that there is a lot of code in place already to produce optimization remarks, and one of my explicit goals is to