search for: paparo

...As I mentioned, this process has to be done in the Assembler, after all the passes and the code emission. In my opinion, the Assembler phase is not a good time to change locations of instructions. Thanks, Omer From: Hal Finkel [mailto:hfinkel at anl.gov] Sent: Sunday, November 20, 2016 23:26 To: Paparo Bivas, Omer <omer.paparo.bivas at intel.com> Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] RFC: Insertion of nops for performance stability ________________________________ From: "Paparo Bivas, Omer" <omer.paparo.bivas at intel.com<mailto:omer.paparo.bivas at intel....

...branch is relaxing it if necessary, and layout for a MCPerfNopFragment will be computing the number of nops it will contain. Can you please refer me to a pre-emit pass that does something similar? Thanks, Omer From: Hal Finkel [mailto:hfinkel at anl.gov] Sent: Friday, November 18, 2016 20:57 To: Paparo Bivas, Omer <omer.paparo.bivas at intel.com> Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] RFC: Insertion of nops for performance stability ________________________________ From: "Paparo Bivas, Omer via llvm-dev" <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists....

Hi all, These days I am working on a feature designed to insert nops for IA code generation that will provide performance improvements and performance stability. This feature will not affect other architectures. It will, however, set up an infrastructure for other architectures to do the same, if ever needed. Here are some examples for cases in which nops can improve performance: 1. DSB

When you say that distribution shouldn't be used, do you mean within instcombine rather than some other pass? Or not all as an IR optimization? A dedicated optimization pass that looks for and makes factoring/distribution folds to eliminate instructions seems like it would solve the problems that I'm seeing. Ie, I'm leaning towards the proposal here: https://reviews.llvm.org/D41574

> On May 8, 2018, at 9:50 AM, Daniel Berlin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > 1. The reassociate pass that exists right now was *originally* (AFAIK) written to enable CSE/GVN to do better. Agreed. The original mindset included a (naive) belief that going with a canonical form was better than teaching redundancy elimination to handle abstractions (as a matter

I mentioned this earlier in the thread - I would like to see something like D41574 in the optimizer. It's optimizing code that no other pass does currently, and I don't see any other near-term proposal that gets us those optimizations. Omer, can you rebase that to trunk? I think a header has moved, so it doesn't build as-is. I'd like to know if it can catch the cases in D45842. If

On Fri, May 11, 2018 at 7:20 PM Hal Finkel <hfinkel at anl.gov> wrote: > > On 05/11/2018 08:40 PM, Daniel Berlin via llvm-dev wrote: > > > > On Fri, May 11, 2018 at 2:37 PM, Hiroshi Yamauchi <yamauchi at google.com> > wrote: > >> >> >> On Thu, May 10, 2018 at 12:49 PM Daniel Berlin <dberlin at dberlin.org> >> wrote: >>