search for: cpu2017

Hi Tobias- The loop fusion you mention is the one in libquantum/cpu2006 ? Or something else in cpu2017 ? -Thx Dibyendu -----Original Message----- From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Tobias Grosser via llvm-dev Sent: Wednesday, August 16, 2017 10:10 AM To: renau at uncore.io; llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] Heroic LLVM optimizations Hi Jose,...

...ser at inf.ethz.ch> wrote: >Sorry, I meant libquantum/cpu2006. > >Best, >Tobias > >On Wed, Aug 16, 2017, at 07:06, Das, Dibyendu via llvm-dev wrote: >>Hi Tobias- >> >>The loop fusion you mention is the one in libquantum/cpu2006 ? Or >>something else in cpu2017 ? >> >>-Thx >>Dibyendu >> >>-----Original Message----- >>From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of >>Tobias Grosser via llvm-dev >>Sent: Wednesday, August 16, 2017 10:10 AM >>To: renau at uncore.io; llvm-dev at list...

...ed, both shall point to elements of the same array object, or one past the last element of the array object (6.5.6.9). So, if the two pointers p and q point to different objects, we can define llvm.psub(p,q) as poison. Other than meeting C specification, correctness of llvm.psub is tested with SPEC CPU2017 and LLVM Nightly Tests as well. But it is true that sometimes pointer subtraction is used to get distance between two objects. Most common case is doing something like 'p - NULL', and this pattern exists in SPEC CPU2017, for example spec_qsort.c in mcf_r . Our suggestion is to define '...

...>> array object, or one past the last element of the array object (6.5.6.9). >> So, if the two pointers p and q point to different objects, we can define >> llvm.psub(p,q) as poison. >> Other than meeting C specification, correctness of llvm.psub is tested >> with SPEC CPU2017 and LLVM Nightly Tests as well. >> > > SPEC and the nightly test suite are great at finding problems, but quite > bad at giving confindence that there are not problems. For subtle things > like this, I would expect you need to look an a much larger sampling of > real-world appl...

Hello all, This is a proposal for reducing # of ptrtoint/inttoptr casts which are not written by programmers but rather generated by LLVM passes. Currently the majority of ptrtoint/inttoptr casts are generated by LLVM; when compiling SPEC 2017 with LLVM r348082 (Dec 2 2018) with -O3, the output IR contains 22,771 inttoptr instructions. However, when compiling it with -O0, there are only 1048

I am a professor at UC Santa Cruz, but I also do consulting a Huawei. Chris Lattner told me that I should post this in the llvm-dev. HiSilicon (Santa Clara office) is looking for some developer capable of implementing the "heroic optimizations" (http://llvm.org/devmtg/2015-10/slides/Gerolf-PerformanceImprovementsAndHeadroom.pdf) in LLVM. Focus on SPEC2006 but also looking at the

Hi Petr- 1. We compile SPEC benchmarks bwaves and xchange currently. We are close to compiling fotonik at this point. 2. We released the source as experimental for the community to take a look. Soon we will open source the entire history of development(we are working on the script to upload the history). thanks, -Prashanth On Mon, Feb 10, 2020 at 4:20 AM Petr Penzin via llvm-dev < llvm-dev

The proposed mitigation for variant 2 of CVE-2017-5715, “branch target injection”, is to send all indirect branches through an instruction sequence known as a retpoline. Because the purpose of a retpoline is to prevent attacker-controlled speculation, we also end up losing the benefits of benign speculation, which can lead to a measurable loss of performance. We can regain some of those benefits