similar to: Bugpoint Redesign

On 6/11/19 12:25 PM, Philip Reames via llvm-dev wrote: At the moment, bugpoint has three major use cases: crash reduction, miscompile reduction, and mutation fuzzing. Out of these, a huge proportion of the interface complexity comes from the miscompile handling. I generally agree with removing the auto-detection logic. I've found it to be extraordinarily error prone and confusing.

"Finkel, Hal J. via llvm-dev" <llvm-dev at lists.llvm.org> writes: > One concern that I have is that, from personal experience, the ability > for bugpoint to reduce the set of optimization passes applied in order > to reproduce a bug is extremely helpful. I understand your desire to > decouple the logic somewhat, and maybe there's some way to generalize > that

I tried to reduce the test case in https://bugs.llvm.org/show_bug.cgi?id=42706. Here it is crashing opt: $ ~/llvm-debug/bin/opt -use-gpu-divergence-analysis -divergence stripped.ll WARNING: You're attempting to print out a bitcode file. This is inadvisable as it may cause display problems. If you REALLY want to taste LLVM bitcode first-hand, you can force output with the `-f' option.

> -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Justin > Bogner via llvm-dev > Sent: Monday, July 22, 2019 11:44 > To: Jay Foad via llvm-dev <llvm-dev at lists.llvm.org> > Subject: Re: [llvm-dev] Fwd: bugpoint can't automatically select a safe > interpreter! > > Bugpoint's user interface is notoriously

Dear all, My name is Mohamed and I am a first year computer science masters student. I am writing this email because I am interested in the project idea "Debug Info Should have no effect on codegen". So far I have built llvm and clang and I was trying to reproduce the problem on simple c++ programs but I can't. Being specific this are the steps I am doing: $ clang -g test.cc > $

Hello everyone, The bugpoint is changed to escalate remote client return status 255 (per discussion - Re: [llvm-commits] [llvm] r75665 - /llvm/trunk/tools/bugpoint/ToolRunner.cpp) Please find the patch attached. -Viktor -------------- next part -------------- A non-text attachment was scrubbed... Name: ToolRunner.diff Type: application/octet-stream Size: 4710 bytes Desc: not available URL:

On Tue, May 23, 2017 at 2:40 PM Reid Kleckner <rnk at google.com> wrote: > We have the LLVM_DISABLE_CRASH_REPORT environment variable, but that's > more about whether we should do crash reporting or not. > > It would be pretty reasonable to have another one to disable all this > stuff. It would also be reasonable to have a cmake option that compiles > this stuff away,

If there are any students looking for ideas, here a couple of projects you might consider. p.s. Anyone know where in the repo the OpenProjects page is? I'd expected it to be the docs/ folder of the LLVM repo, but it wasn't. Transactional Memory Optimization Intel recently introduced transactional memory support in hardware. This project would consist of implementing optimizations

Hi Everyone, Here are my notes on the LLVM 1.7 release, which will go into the final release announcement. As Tanya mentioned, it has been far too long since the last release, and there have been a lot of CVS commits since Novemeber. :) I went through them all and pulled out some of the major improvements, which I've listed below. I'm certain that I have forgotten some things, so

Thank you very much for your suggestions. That's very helpful. However, since I'm trying to compile several somewhat large projects, I assume generating bitcode for each single file and linking them together might be painful (I don't want to modify too much the project makefiles). So I hope my pass can be used just with simple compilation command like "llvm-gcc

It seems that bugpoint (and llvmc2, etc.) is hard-wired to use gcc to do assembling and linking. I want to bugpoint-reduce a testcase that came from Fortran and so I need to invoke our compiler to do at least the linking step to get our Fortran libraries. Is there a way to do this via bugpoint's command-line interface or do I have to hack bugpoint's source? I can see how I might make

Dave, The way I see it there should be just one pass that implements deleting UB (maybe it would come to be called UBCE), and that one pass should have a command line option simply for the reason than all passes should have one. Peter Lawrence. > On Jul 26, 2017, at 10:02 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Wed, Jul 26, 2017 at 9:23 PM

On 10/29/10 1:26 PM, Eli Friedman wrote: > Sure, but you know which induction variables you created; you can just > zap the unused ones at the end of the pass, no? This is feasible. We would have to collect more information during OSR proper pass and add logic to cleanup at the end. >> FWIW I noticed that other optimizations (as seen in StandardPasses.h) are >> followed by

Feedback below.. > <will insert overview blurb here> Big new things: llvm-gcc4, new sparc > backend, Generic vector/SSE/Altivec support, X86 Scalar SSE support, > debugging support, many target-independent codegen improvements, inline asm, > llvm.org/web-reg. > > > Core LLVM IR Improvements: > > * The LLVM IR now has full support for representing

Hi All, I'm putting together the announcement for the LLVM 1.6 release. Here is what I have so far. Because so much has been done, it is very likely that I have forgotten something. If you have done something that is not on the list, please send me a private email so I can add it (also, please tell me if I've made a mistake or miscredited something)! My next project is to start

Hi all, This is about a project I've been prototyping on-and-off for a while that has finally reached a point where I can claim it to be "potentially viable". I'd like to gather some input from the community before moving too far ahead. # The problem There is a representation issue within SCEV that prevents it from fully using information from nsw/nuw flags present in the

Hi , I am using LLVM for my Post Graduate course project on Optimization. I am trying to do some insrtumentation to the bytecode.I 've been going through your Instrumentation code for the past few days in /llvm/lib/Transforms/Instrumentation folder and finally found two ways of instrumentation : 1) injecting LLVM bytecode instructions 2) calling an external C function. I am trying both and

On Sat, Dec 17, 2016 at 6:39 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> On Dec 17, 2016, at 1:35 PM, Davide Italiano via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> First of all, sorry for the long mail. >> Inspired by the excellent analysis Rui did for lld, I decided to do >> the same for llvm. >> I'm personally very

David, -fsanitize=undefined sounds great, but is not quite what I want. I recently ran into a problem with "CodeGen/MachineSink.cpp” [*], for a target that has to expand Select into control flow. The original IR had two select in a row that were based on the same condition, so the CMP that sets the FLAGS reg in the second select was MCSE’ed to the earlier CMP in the first

> On Dec 17, 2016, at 1:35 PM, Davide Italiano via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > First of all, sorry for the long mail. > Inspired by the excellent analysis Rui did for lld, I decided to do > the same for llvm. > I'm personally very interested in build-time for LTO configuration, > with particular attention to the time spent in the optimizer. >