search for: minyihh

The Loop Optimization Working Group had a survey about “canonical” loop required by each loop transformation or analysis. That is, what should we normalize a loop before running a certain loop pass. Here is the survey result: https://tinyurl.com/rhuzny2 (Note that there are two workspaces: “By precondition” and “Breakdown”) Best - Min > On Dec 22, 2019, at 2:40 AM, Shraiysh Vaishay via

> On Aug 8, 2020, at 3:32 PM, Dmitry Mikushin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Cool, thanks! > > вс, 9 авг. 2020 г. в 00:27, Petr Hosek <phosek at chromium.org <mailto:phosek at chromium.org>>: > You can set the LLVM_PARALLEL_LINK_JOBS CMake variable to restrict the number of link jobs. IMO, a more thorough solution would be switching to

On Mon, 28 Sep 2020 at 19:13, Min-Yih Hsu <minyihh at uci.edu> wrote: > Thanks for all your feedback, those were extremely helpful, especially the > guidelines to split the patches. I think in my case, patch 3 ~ 6 are the > most problematic, I will rework them shortly. > Perfect, thanks! And most importantly, I'll present a ro...

Hi everybody, I'm trying to get loop hotness data across a suite (e.g. the llvm test-suite). Ideally, this would be a list that for each loop would list how many times it was entered and what was its iteration count (at least the latter). The closest thing I could come up with is: - clang -fprofile-instr-generate (without opts) to get a .profraw - Get the .profdata - Give that back to clang

On Mon, 28 Sep 2020 at 10:37, John Paul Adrian Glaubitz < glaubitz at physik.fu-berlin.de> wrote: > So, I think in case there was a problem with the backend in LLVM, the > community > would have enough momentum to work towards solving this issue. > Great! I agree. But we will enable the target in Debian the moment it becomes > usable > and we will expose it to as much

On Wed, Sep 9, 2020 at 9:23 PM Wenlei He via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I think calling PGSO size opt is probably a bit misleading though. It’s > more of an adaptive opt strategy, and it can improve performance too due to > better locality. We have something similar internally for selecting opt > level based on profile hotness too under AutoFDO. > >

We would like to propose a new feature to disable optimizations on IR Functions that are considered “cold” by PGO profiles. The primary goal for this work is to improve code optimization speed (which also improves compilation and LTO speed) without making too much impact on target code performance. The mechanism is pretty simple: In the second phase (i.e. optimization phase) of PGO, we would add

Hi all, Apparently some people had trouble joining today. I also had trouble using the attendee ID provided by webex. I've canceled the meeting series and will be scheduling a new one with an updated link. Please remember to update your calendars with the new invite. My apologies to those who couldn't join today, and to everyone for the churn. Today's Meeting Minutes:

Hello, Min. I suppose I should ask you this: what do people need to know before working with LLVM? Could a book work with that and link it to LLVM specifically? Thanks, Matthew On Sat, Aug 15, 2020, 7:06 PM Min-Yih Hsu via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi Matthew and all, > > Also I feel like one of the obstacles would be the fast-changing APIs. > Since to

Hi All, We would like to contribute our supports for Motorola 68000 series CPU (also known as M68k or M680x0) into LLVM. And we want to hear feedbacks from you Here is some background for M68k: Motorola 68000 series CPU was one of the most popular CPUs used by personal computers in the ‘80, including some of the earliest Apple Macintosh. Fast-forwarding to modern days, M68k is still popular